I am writing a script to do an unattended install of VirualBox. Given the name for the partition to which applications are installed isn't always "Macintosh HD", how do I detect the name of the main install partition for application installs?
You don't need it. The instructions in the VirtualBox manual are unnecessarily complex; you can always install a package to the root filesystem by specifying the target as -target /.
(In fact, the path under /Volumes representing the current root filesystem is always just a symlink to /.)
Related
I would like to release my program that wrote in ruby language, I need to pack ruby to appimage file and send it to my client ubuntu PC first.
so I create the folder "ruby-img", then copy my compiled ruby which in "/app/ruby" folder to "ruby-img/app/ruby" and then made a link as "ln -r -s app/ruby/bin/ruby usr/bin/." in "ruby-img" folder.
then I create the desktop file and put png file to "ruby-img", using appimagetool to create ruby-x86_64.AppImage. sadly it can not run, AFAIK that ruby.AppImage still using /app/ruby/lib folder to find some library of ruby but not in "ruby-img/app/ruby/lib" related folder.
so I tried re-compile ruby as --prefix=/tmp/ruby or --prefix=/usr/local/ruby, then copy them to "ruby-img/usr/local/ruby" or "ruby-img/tmp/ruby" then maka some link as above, and repack to AppImage but ruby.AppImage still not working...
any idea can help me ?
AppImages contain of a filesystem with all the content you provide plus a small executable stub that will mount the AppImage filesystem, then run the AppRun executable to be found inside.
With that knowledge it is utmost important that you provide an executable in the root directory along with the .desktop and icon files. I suggest you do not create AppRun yourself. Use the precompiled one from https://github.com/AppImage/AppImageKit/releases/tag/continuous (do not forget to rename it to exactly 'AppRun').
Now when this AppRun gets invoked, it will perform a few checks, cd into the /usr directory and try to start the executable specified in the .desktop file. Check it's source code and you can see that it also sets a few environment variables.
Therefore it is best you provide your entrypoint as /usr/bin/ruby.sh and register that in the desktop file. Remember if /usr/bin/ruby.sh gets called, the current work directory is /usr. So ruby.sh can set further environment variables such as LD_LIBRARY_PATH so that the libraries you configured for /usr/lib will actually be loaded.
With that I hope you have at least as much success as I had.
I'm learning to use GNU/Linux and I want to know how to install programs that cannot be installed with the package manager.
I downloaded the tarball with the Linux 64-bit Binaries (including one called "haxelib"), extracted it, changed directory in the terminal to their location (~/Downloads/things/haxe_20201231082044_5e33a78aa/), and used chmod to make them executable.
If I try a command such as haxelib list, then the terminal returns
haxelib: command not found
If I try ./haxelib list (the same command but with ./ at the start) instead, then the command works as expected.
Why can't I use it without the ./? Programs installed with the package manager can be used without the ./.
Edit: I should probably also ask: where should I put the files from the tarball? Should they all go together in the same place? I have a feeling that a folder named "things" in my Downloads folder is not the best place for them.
I'm following this online book in my path to learn Go during the weekends.
I've tried running the go help gopath command it just returns example paths and how they relate to each other in packages and source directories - it's doesn't actually say where I can find the go folder.
The book specifically mentions:
First create a new folder where we can store our program. The
installer you used in chapter 1 created a folder in your home
directory named Go. Create a folder named
~/Go/src/golang-book/chapter2. (Where ~ means your home directory)
From the terminal you can do this by entering the following commands:
I used the default installer on the Go homepage, so assume that everything installed in the default folder the installer comes with.
If I cd in terminal to the ~/ folder and then use ls, there is no /Go folder.
How can I find this folder in order to follow the online book properly? I'm assuming he's using this folder structure for a reason and would rather not deviate and learn how packages work, etc.
The instructions say:
Create a folder named ~/Go/src/golang-book/chapter2
I interpret that to mean that YOU create the folder named "~/Go/src/golang-book/chapter2". The installer doesn't create this, but you can.
E.G. in your Terminal:
mkdir ~/Go
mkdir ~/Go/src
mkdir ~/Go/src/golang-book
mkdir ~/Go/src/golang-book/chapter2
Goal
I am trying to create a port (Macports) for an open source tool based on Eclipse which doesn't need installation, in other words, it's just "extract and use" case. Users can download the tool from the official project site and use just like that. So there is no DESTROOT variable set.
Since many Mac users got used to the convenience of Macports, I would like to add the tool there, so that users could instantly install or uninstall the tool.
** Important notice: once users start the tool, it creates "/workspace" directory in the same place the tool was installed to keep users' preferences, settings, and other necessary files. So, when users starts the tool, the program should have access to write in the same directory it was installed. The current version of the tool doesn't provide a way to choose the workspace location.
Problem
How should I organize the Portfile?
I have set the following configurations where I tell Macports to not use configure, build, and destroot phases.
set cm_workspace /workspace
universal_variant no
use_configure no
supported_archs noarch
post-extract {
file mkdir ${worksrcpath}${cm_workspace}
destroot.keepdirs-append ${worksrcpath}${cm_workspace}
}
build {}
destroot {}
As I understand,
extract phase untars the file,
and install phases should archive those files,
and finally activate phase should move the files to the destroot.
But I keep getting errors.
---> Extracting cubridmanager
---> Configuring cubridmanager
---> Building cubridmanager
---> Staging cubridmanager into destroot
Error: No files have been installed in the destroot directory!
Error: Please make sure that this software supports 'make install DESTDIR=${destroot}' or implement an alternative destroot mechanism in the Portfile.
Error: Files might have been installed directly into your system, check before proceeding.
Error: Target org.macports.destroot returned: Staging cubridmanager into destroot failed
Log for cubridmanager is at: /opt/local/var/macports/logs/_Users_nbp_macports_databases_cubridmanager/cubridmanager/main.log
Error: Status 1 encountered during processing.
To report a bug, see <http://guide.macports.org/#project.tickets>
I want to contribute to that open source community, but I can't pass this step.
You misunderstood the phases, the usual workflow is as follows:
extract untars the downloaded file
patch applies any local patches
configure runs ./configure
build runs make
destroot runs make install DESTDIR=${destroot}
install packs the file in the destroot area into an archive
activate moves the files into ${prefix}
So, in your case, you don't need steps 2, 3 and 4. But you still need to copy the files to the destroot area in step 5, the destroot phase. Otherwise MacPorts does not know which files it is supposed to install.
supported_archs noarch
use_configure no
build {}
destroot {
copy ${worksrcpath} ${destroot}${prefix}/some/path
}
Note that MacPorts does discourage installing files outside the prefix directory, as the installation is meant to be self-contained. The path /workspace sounds like a pretty bad idea. Rather, you should use a path inside the users home directory to save any data as otherwise this cannot be used on a computer with multiple user accounts. Of course, the actual executable files can reside in the MacPorts prefix.
Normally, UNIX software separates binaries, libraries and shared data in /usr (or in the MacPorts case,/opt/local) from user-specific data in the home directory. If your tool does not follow this convention, this needs to be fixed by the developers first.
I don't think that tool fits with macports for related reasons
All files from macports should be in one of the supported directories i.e. destroot and ending up in /opt/local
The project tries to write to sub directories which is not good here
The directories written to bu macports can only be written to by the user macports so as to minimize the ability to affect the build and run environment.
In a multiuser system who owns the directory to write to? e.g. macports are installed as user macports and are run as someone else - Also if there are more than one normal user who writes to the directory?
I think you need to patch the tool so that it is passed a directory to create the workspace in when a normal user runs it but the tool is install as ownwd by macports in /opt/local/bin
I got a pkg file in which I can change the installation directory when launched using the UI, but the manpage of installer only mention the target drive to install to.
Is there an environement variable to set when calling the installer ?
About the target options, from installer help :
The -target <device> parameter is any one of the following:
(1) One of the domains returned by -dominfo.
(2) Device node entry. Any entry of the form of /dev/disk*.
ex: /dev/disk2
(3) The disk identifier. Any entry of the form of disk*. ex: disk1s9
(4) Volume mount point. Any entry of the form of /Volumes/Mountpoint.
ex: /Volumes/Untitled
(5) Volume UUID. ex: 376C4046-083E-334F-AF08-62FAFBC4E352
So target is a "hard drive", not the "root path" where the pkg should be installed.
Most package managers include options to relocate (that is, change the installation path of) a package, on RPM-based Linux systems rpm has the option -relocate, on OS X, command line tool installer has the option -target.
However, as you have noticed, you can't specify an arbitrary path as argument to -target, as you would do with rpm's -relocate
The arguments to -target are limited to (see man installer):
A volume mount point (/Volumes/HDD), device node (/dev/disk0s5) or volume UUID (376C4046-083E-334F-AF08-62FAFBC4E352).
Any of the values returned by -dominfo (like LocalSystem or CurrentUserHomeDirectory), for example.
You write:
I got a pkg file in which I can change the installation directory when
launched using the UI
If that's the case, that information can probably be queried with -dominfo like this:
installer -verbose -dominfo -pkg <path to your package>
and can be used when installing from the command line:
installer -pkg <path to your package> -target <dominfo as listed above>
(I have queried several pkg files and all return NoDomainsAvailable, so can't share any experience.)
Keep in mind that, though, you can't arbitrarily relocate a pkg file. The reason is that configuration files, binaries and libraries included in the package usually specify or depend on absolute paths.
The package builder must actively convert those into relative paths (using postinstallation scripts and techniques like #rpath). So, generally speaking, you can only relocate a package that has been built with relocation in mind.
Your question is quite unclear: If you run the installer from the GUI and there is only one drive offered to install to, you can not change it in an easy way (means: you have to make changes to the installer package to install in a different location than offered by default).
Since you are using the "cli"-Tag (command line interface), I think you are trying to run the installer not on the GUI, instead you are running it from the terminal. There you have more options: With the -target option, you can set the installpath for your installer.
Information from the man-pages on the -target-Option:
The target volume is specified with the -target parameter ( -tgt is
accepted as a synonym). It must already be mounted when the installer
command is invoked.
Additional informations on how to run an installer from the Terminal (cli), you will find on my blog.