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.
Related
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?
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.
Question:
Is there a way to install a downloaded NBM (Netbeans Module) into an already installed Netbeans IDE via CLI?
Current setup
Netbeans 12.3 with Windows 10
Netbeans 12.3 with Linux Mint 20.1
Relevant scenario
If the question comes to your mind 'why aren't you just using the GUI?' or anything like that. Think of the following scenario. When working on an air gapped network with 50 computers you're the one having to install Netbeans plugins on all of that PCs. You're able to put files on those PCs and execute a command via console and you don't want to run around all the buildings and clicking through the process.
Thank you very much in advance.
I think I found a solution. I'll post it here to reflect my research because I've never found a answer on stackoverflow.
When Netbeans is already installed you can use the --help parameter like:
C:\Program Files\NetBeans\netbeans\bin\netbeans64.exe --help
This lists lot of available parameters (which I haven't found a list of on the web) like (shortened):
General options:
--help show this help
--jdkhome <path> path to JDK
--console new open new console for output
Module reload options:
--reload /path/to/module.jar install or reinstall a module JAR file
Additional module options:
--modules
--refresh Refresh all catalogs
--list Prints the list of all modules, their versions and enablement status
--install <arg1>...<argN> Installs provided JAR files as modules
--disable <arg1>...<argN> Disable modules for specified codebase names
--enable <arg1>...<argN> Enable modules for specified codebase names
--update <arg1>...<argN> Updates all or specified modules
--update-all Updates all modules
Core options:
--fontsize <size> set the base font size of the user interface, in points
--userdir <path> use specified directory to store user settings
--nosplash do not show the splash screen
In my case the solution was to use the --install parameter pointing to the jar file to install.Be aware that the NBM files are just containers containing the jar file and some more meta data files like config xml files. You're able to open it via 7zip for example. And you'll have to take care of all the dependencies yourself.
I'm looking into running Swift on a Ubuntu 16.04 server. However I want to be certain about where I should install the toolchain.
From swift.org:
If you installed the Swift toolchain on Linux to a directory other than the system root, you will need to run the following command, using the actual path of your Swift installation...
Then from Kitura's Setting Up instructions:
After extracting the .tar.gz file, update your PATH environment variable so that it includes the extracted tools:
$ export PATH=<path to uncompressed tar contents>/usr/bin:$PATH
Where is the best place to install these type of things? In the past I would rely on apt-get or installation scripts provided by maintainers but this doesn't seem to be the case with Swift.
Are there any benefits or disadvantages to not installing it at the system root?
Note: This question borders on "best practices", which I believe is frowned upon here. I'm sorry about that; I've googled around and this seems to be something that people know implicitly. However, I don't yet and need some guidance
The versions of the software in your system root - in /usr/bin, /usr/share, /usr/lib, etc. - are carefully coordinated by the maintainers of your distribution to handle all reasonable dependencies. The maintainers also keep the software up-to-date with bug fixes.
When you need to install software that isn't supplied by your distribution, it's best to install it in a separate directory, such as /opt (in your case, one possibility is /opt/swift-3.1.1). This will avoid overwriting existing installed software (in your case, /usr/bin/lldb and /usr/lib/lldb) with something that's possibly incompatible with other software. And it will make it easy to uninstall (just rm -r /opt/swift-3.1.1 rather than having to get a list of files from the original tarball that are potentially strewn all over /usr).
There is some extra effort: you'll need to add /opt/swift-3.1.1/usr/bin to your PATH1. With some software, you'll need to add the directory containing dynamic library files to LD_LIBRARY_PATH. The software's installation instructions typically explains what you need to do.
[1]An alternative to changing PATH is to add a symlink to each new executable, in a directory that's already in your PATH. GNU Stow can help you do this.
I am creating rpm for apc. While writing spec file, I realized that some commands may have path which can keep on changing which are required during the compilation time. For eg. these commands are required to be executed during the building time.
$ /usr/local/php/bin/phpize
$ ./configure --with-php-config=/usr/local/php/bin/php-config
But the complete path of phpize and php-config file may change. So how can i prevent this dependencies so that i should not hard-code these path in my spec file.
Because these commands are used at building time, the ideal solution to this problem is here:
Find packages on distribution which provide these commands or paths e.g php-config is provided by php-devel package on Fedora operating system. In fedora you can find it using yum whatprovides "*/php-config" or if they are already installed on system then using rpm -qf /path/to/command.
Once you know the packages add them as BuildRequire tag in spec file. Step 2 will make sure that paths are always present whenever you build the package from spec file even if you use hard coded paths (which isn't ofcourse best way to do it).
In place of /usr/ you can use %{_prefix}, it depends entirely on macros available on distribution you are building this rpm on. Check macro files for path macros. One link which has common macro definitions is here.