I'm developing a free guitar VST plugin that I want to distribute through a .deb package.
In the postinst script, I run the xdg-desktop-menu command to create the launcher for the standalone version (which works fine), but DAWs (like reaper and bitwig) will look for vst plugins inside $HOME/.vst and obviously won't find my plugin there.
At first I thought I needed to create a symlink inside $HOME/.vst but now I know debian packages aren't supposed do anything inside the user's folder. So what should I do instead?
Related
I have a Yocto system where I'm running some Chef InSpec scans. Chef InSpec offers a command to check if a package is installed, however, that doesn't work with Yocto (I imagine it would if you'd install a package manager, but I don't want to do that). What would be the best way to check if a certain package is installed on the system?
I know that bitbake can show every package that would be in the built image, but I need to check on the target system. Is there a way I can get this information from bitbake from within a recipe that would just route the output into a file on the rootfs? Or is there a better approach without installing a package manager on the target system?
Inside the folder tmp/deploy/images/$MACHINE/${IMAGE}/
You should see a file named with manifest extension. It is often named like this : [image-name]-[image-version].manifest"
In this file you will find all packages that are present in your linux image built with Yocto, so packages that will be deployed in your target.
I have written a program consisting of a few .py-scripts, which I am able to successfully make into one package via wheel and bdist and upload it to pypi.org via twine, from where I can download and install it via "pip install".
I have 3 or 4 configuration-files, that are kept in .txt-format and my program optionally uses those configuration-files to configure itself when it starts.
Is there a way to somehow integrate those .txt-files into that package and upload it, so when someone does "pip install", he not only installs the programm, but automatically also gets those 3 .txt-files into a certain directory?
I am currently installing into /opt/mycompany/. I have 2 components in my installation and they are installed as /opt/mycompany/foo and /opt/mycompany/bar.
Is it possible to directly install my components into /opt like /opt/foo and /opt/bar.
As the media configurations require us to specify a directory(mycompany) inside /opt where our components gets installed, I am not able to achieve what I want.
Currently I am using symbolic links to achieve this. Is there a better solution available for this ?
In the distribution tree, add an installation root /opt and add files under that root. See
https://www.ej-technologies.com/resources/install4j/help/doc/concepts/files.html
for more information.
However, you always need an installation directory that is not directly /opt, because it contains the .install4j runtime directory.
I would like to use install4j to make it easier to deploy my Java application to Windows, Mac, and Linux. I am evaluating install4j on my Windows development machine to make sure it can do what I need before I purchase it.
So far, I can get it to work for Windows and Linux but not for the Mac. The Mac app bundle that I cobbled together (without install4j) currently has the following structure where the Java dir contains external jar files (such as derby.jar) required by my application.
myApp.app
Contents
MacOS
Resources
Java
Perhaps I can use a simpler structure but this is what I have for now and it works. Unfortunately, the structure install4j builds does not work (it cannot find my derby.jar) and I cannot figure out how to get install4j to duplicate the app bundle directory structure that I know does work.
Any suggestions?
I maintain multiple Perl written (unix-ish) applications whose current installation process consists of a manually written Makefile and installs configuration files into /etc/.
I'd really like to switch their development to use Dist::Zilla, but so far I haven't found any Dist::Zilla plugin or feature which allows me to put given files into /etc/ when the make install (or ./Build install in case of using Module::Build instead of ExtUtils::MakeMaker) is run by the local administrator who's installing my application.
With pure ExtUtils::MakeMaker, I could define additional make targets in MY::postamble and the let the install target depend on one of them via the depend { install => … } attribute. Doing something similar, but via dzil build, would probably suffice, but I'd appreciate a more obvious way.
One orthogonal approach would be to make the application not to require the files under /etc/ to exist, but for just switching to Dist::Zilla that seems to much change in the actual code despite I only want to change the build system for now.
For the curious: the two applications I currently have in mind for switching to Dist::Zilla are xen-tools and unburden-home-dir.
The best thing to do is to avoid installing files into /etc from any Perl distribution. You cannot ensure that the cpan client (or the installing user) has permissions to install there, and there can be multiple Perls installed on a system, so each one of them would clobber the /etc files of another install. You can't really prevent the file from being overwritten by a subsequent install, so you shouldn't put config data there that you don't want to lose.
You could put the config file in /etc/, if the application knows to look for it there, but you should allow for that path to be customized (say on a test system, look for the file in the local directory, or in a user's home directory).
For installing read-only module-specific data, the best practice in Perl is to install into a Perl-install-specific location, and the module to do that is File::ShareDir::Install. You can use it from Dist::Zilla using the [ShareDir] plugin, Dist::Zilla::Plugin::ShareDir. It is even included in the [#Basic] plugin bundle, so if you use [#Basic] in your dist.ini, you don't need to do anything at all, other than drop your data files into the share/ directory in your distribution repository.
To access the contents of the sharedir from code, use File::ShareDir.
For porting a complex module installer to Dist::Zilla, I recommend my plugins MakeMaker::Custom or ModuleBuild::Custom, depending on which installer you prefer. These allow you to keep your existing Makefile.PL or Build.PL and just have Dist::Zilla plug in necessary bits like the dependencies.