GNU Autotools: install binaries in / bin, / sbin, / usr / bin and / usr / sbin, interactions with --prefix and DESTDIR

Question

Most packages that use autotools are user-level utilities, or at least high enough that are completely under / usr, or low enough to be completely lower than / usr.

I am writing a package that would have to install some files in / bin, some in / sbin, / usr / bin and / usr / sbin. It replaces several existing binaries that are traditionally located in these places.

You also need to install the PAM module in / lib / security (and obviously / usr / lib / security will not work).

Now the problem is that the default prefix by default is / usr / local (I can control this default in my configure.ac file), and at least for Gentoo Linux the default is --prefix = / usr (this problem because it overrides all the default values ​​that I entered in my configure.ac file).

I briefly looked at how other similar packages deal with this problem. Here are my findings:

• bash -4.1 seems to be installed in / usr / bin, and distro build scripts move the bash binary to / bin
• Linux-PAM has hacks in the configure.ac file, so if the prefix is ​​"/ usr", it will use "/ sbin" and "/ lib" for some of its files. It also sets the default prefix for "/ usr". I'm not sure what will happen if the user passes another -prefix.
• shadow-utils sets exec_prefix to "" if the prefix is ​​"/ usr". Then bin_PROGRAMS refers to "/ bin", and Ubindir is declared as "$ {prefix} / bin", so ubin_PROGRAMS refers to "/ usr / bin"

My questions:

• What are the other distros settings for -prefix? Can I reasonably assume this is always / usr? At the moment, I'm only concerned about Linux, not BSD.
• Which of the above solutions seems the cleanest? Do you see some better solutions?
• What are the potential problems with the above solutions? Are there any solutions to these problems?
• I am fine with installing everything in "/ bin" and creating symbolic links for compatibility. Does this simplify the task?
• Is there another common build system acceptable for low-level system utilities that better handle my requirements?

Feel free to ask what I'm trying to do. Please note: if I want to maintain compatibility with what I replace, if he used to send the binary A and B, one of them / sbin and one in / usr / bin, I think I just need to put the replacements in these places or Less have symbolic links. PAM modules also have a fixed installation location.

I am obviously going to put forward any useful answer. I am the "accepted answer." I mainly seek advice "what should I do", what is the purest solution to the problem and, if applicable, a discussion of options and disadvantages, pluses and minuses.

Answer 1

Essentially, the distinction between the / and /usr hierarchies is not and should not lie in the hands of a third-party developer (see the "Not Your Responsibility" section). Since / should only contain the files needed to download and create /usr , this is an administrative decision that goes to / . For installations from the source, this decision is made by the installer, and for distributions, the proponent of the package.

To justify, suppose someone is trying to create a chroot environment. The distinction between / usr and / does not make sense in the environment and will not be made. All prefixes are set to /foo/bar/chroot , and any script messing configuration with $prefix can cause strange behavior. The same arguments apply to scripts, such as Debian package helpers, which rely on the usual semantics of $prefix to work.

So the cleanest solution is bash-4.1 . You have basically two clean options: Split your package into bootable and non-bootable critical parts or let your configure script offer an alternative prefix for boot-critical parts, which is set to / by default, leaving $prefix as /usr .

Answer 2

There are two different levels in this question, and your questions seem to apply to the second value (the binary package generated by your * .spec file, or debian / rules, or * .pkg. File) as automata, you DO NOT LEAVE. You should not try to specify a default prefix other than / usr / local in your configure.ac file. The indication of where things should be installed is done in the binary package management files, NOT in the configure.ac file. Source distribution using the autoconf configure script created must be set to / usr / local by default, and everything else is a packaging error.

If you want to have a source distribution that the user can easily install to install in a specific location on a specific platform, it would be acceptable to include a script in the tarball that does this. For example, you can add a script construct that looks something like this:

  #! / bin / sh

 case $ 1 in
 foo) args = '- prefix = / usr --bindir = / bin --sysconfdir = / etc' ;;
 bar) args = '- prefix = / opt' ;;
 *) args = ;;
 esac
 $ (dirname $ 0) / configure $ args &&
 make &&
 make install

which will provide default arguments for the settings for the "foo" and "bar" platforms, but it really sounds like your questions are about management files for binary packages.