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.
Related
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 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 /.)
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
Being new to packagemaker I assume I am just missing something. It does not seem all the options in the GUI are available from the command line. I have read the man page but maybe I just don't get it.
Of most interest to me is how do I specify the install locations of the files?
From the commandline to I need to also use installer in combination with packagemaker to get the same results of the GUI packagemaker? If so are there any examples you can recommend?
Thanks
Vincent
What I ended up doing to change the install directory from command line:
create the package
extract the new package with pkgutil
string search for install-location="/" in the pkg file's PackageInfo, replace with desired install location
repackage with pkgutil
That works.
If you are creating packages using commandline mode of packagemaker, you will have to create a dummy directory which contains all your files in proper location. For example, if you have to install files A and B at /Library/Applications/ and /Library/Application Support/ respectively, then you create the structure as below.
Create a temp directory, say SourceFiles.
Add your files to this directory as follows-
SourceFiles/Library/Applications/A
SourceFiles/Library/Application Support/B
Now use the flag --root in packagemaker commandline mode.
packagemaker --root SourceFiles/ OTHER_OPTIONS
The idea is that instead of passing location of individual files to the command, you create a similar structure in a temporary directory and just pass that directory as argument to --root flag.
More for commandline mode of packagemaker:
http://macinstallers.blogspot.in/
Zip-Archive mode works on systems with zip/unzip. How do you get it to work on Wnidows?
EMACS uses an external program to do the compression/uncompression. All it needs is to know the right program to use.
Some extended discussion:
As I say, i've got no Windows box, but the LISP code is in arc-mode.el at about line 230:
(defcustom archive-zip-extract
(if (and (not (executable-find "unzip"))
(executable-find "pkunzip"))
'("pkunzip" "-e" "-o-")
'("unzip" "-qq" "-c"))
"*Program and its options to run in order to extract a zip file member.
Extraction should happen to standard output. Archive and member name will
be added."
:type '(list (string :tag "Program")
(repeat :tag "Options"
:inline t
(string :format "%v")))
:group 'archive-zip)
Observe the function executable-find. It searches in your EMACS exec-path, which includes some EMACS executable directories that aren't in your normal PATH variable. In my case, it's:
("/usr/bin"
"/bin"
"/usr/sbin"
"/sbin"
"/Applications/Emacs.app/Contents/MacOS/libexec"
"/Applications/Emacs.app/Contents/MacOS/bin"
"~/bin"
"/usr/local/bin"
"/usr/X11R6/bin")
which includes the two directories inside the EMACS package. Your Windows installation will include equivalent directories somewhere down in the guts of the EMACS setup. That's where to look for the executables if they're not in your regular path.
You can download pkunzip from this site, install it, and add the path to the installation with (add-to-list 'exec-path "c:/path/to/pkunzip")
How emacs handles compressed files can be a little confusing, but here is an attempt to summarise the situation. There are two main compression packages: arc-mode (e.g. zip-archive mode) and jka-compr mode (auto-compression-mode).
arc-mode: will display the table-of-contents (i.e. simple list of filenames contained within the archive) of multi-file archives (arc, lzh, zip, zoo) without requiring the relevant third-party tool to exist on your system. If you actually want to do any viewing/editing of the actual files contained within the archive using arc-mode you will definitely need the third-party tool to be installed on your system and in the appropriate location. E.g. for zip files it defaults to zip/unzip in the exec-path (which is the operating systems PATH environment). This can be customised using archive-zip-extract and archive-zip-expunge.
jka-compr (auto-compression-mode): will automatically compress/uncompress single file archives (gz, Z, bz2, tbz, etc) and requires the relevant third-party tool to exist on your system.
So to get zip-archive mode fully working on Windows you will just need to find a windows version of command-line zip/unzip and put them into a directory that is in your PATH (e.g. see unzip package at http://gnuwin32.sourceforge.net/).
you can use [chololatey]: https://chocolatey.org/ , the package management for windows , to install unzip.
choco install unzip