[pacman-dev] use of /usr/local with pacman
I just updated the installed pacman and noticed makepkg.conf's use of /usr/local in strip, doc, and man dirs. Should pacman allow any files to be installed into /usr/local? I've been an administrator on various UNIX clones for more than a decade and packages that were installed by the package manager, whether precompiled or a build recipe, always avoided /usr/local and any "local" modifications were put exclusively in /usr/local with PATH and library search path having /usr/local first so the user's modifications would take precedence. Just curious if pacman makes such a policy or if it is up to the PKGBUILD author. -- Jeff My other computer is an abacus.
Jeff wrote:
I just updated the installed pacman and noticed makepkg.conf's use of /usr/local in strip, doc, and man dirs. Should pacman allow any files to be installed into /usr/local? I've been an administrator on various UNIX clones for more than a decade and packages that were installed by the package manager, whether precompiled or a build recipe, always avoided /usr/local and any "local" modifications were put exclusively in /usr/local with PATH and library search path having /usr/local first so the user's modifications would take precedence. Just curious if pacman makes such a policy or if it is up to the PKGBUILD author.
Entirely up to the package author. Pacman just manages the packages. Allan
On Thu, Aug 20, 2009 at 2:31 AM, Jeff
I just updated the installed pacman and noticed makepkg.conf's use of /usr/local in strip, doc, and man dirs. Should pacman allow any files to be installed into /usr/local? I've been an administrator on various UNIX clones for more than a decade and packages that were installed by the package manager, whether precompiled or a build recipe, always avoided /usr/local and any "local" modifications were put exclusively in /usr/local with PATH and library search path having /usr/local first so the user's modifications would take precedence. Just curious if pacman makes such a policy or if it is up to the PKGBUILD author.
I am confused. Are you talking about the package manager pacman, or about the package themselves? What you mention with '/usr/local' is just a autoconf default : http://sunsite.ualberta.ca/Documentation/Gnu/autoconf-2.13/html_node/autocon... And this concerns the files of pacman itself, not the packages that will be installed by pacman. And when you build and install any software manually, without using the official package manager, it should be seen as a local modification. So it is good to have the build system use /usr/local by default.
On Thu, Aug 20, 2009 at 08:34:18AM +0200, Xavier wrote:
I am confused. Are you talking about the package manager pacman, or about the package themselves?
Sorry for the really late reply. Technically, I'm talking about makepkg. To rephrase, I was asking if pacman (or makepkg) has a policy disallowing installation to /usr/local or if it would install anywhere the PKGBUILD was written for. Allan McRae answered that it was up to the PKGBUILD. The question was prompted by the 3.3 release which added /usr/local to the {DOC,MAN}_DIRS. Of course I completely missed that /usr/local was already specified in STRIP_DIRS prior to 3.3. I skimmed through the diff too quickly! ;)
What you mention with '/usr/local' is just a autoconf default : http://sunsite.ualberta.ca/Documentation/Gnu/autoconf-2.13/html_node/autocon...
To be more precise, /usr/local is not the standard because of autoconf. autoconf uses /usr/local as the default because the standard already existed in various flavors of UNIX.
And when you build and install any software manually, without using the official package manager, it should be seen as a local modification. So it is good to have the build system use /usr/local by default.
If by build system you mean manual compiling, I agree completely. Going one step further, though, the argument could be made that a package manager should not even be able to install to the local prefix because the package manager belongs to the realm of system packages not local packages, but don't mistake this as me asking for such a "feature". :) BTW, I don't recall which devs added the splitpkg functionality, but I LOVE it! Thanks a million! -- Jeff My other computer is an abacus.
On Sun, Sep 6, 2009 at 8:03 PM, Jeff
And when you build and install any software manually, without using the official package manager, it should be seen as a local modification. So it is good to have the build system use /usr/local by default.
If by build system you mean manual compiling, I agree completely. Going one step further, though, the argument could be made that a package manager should not even be able to install to the local prefix because the package manager belongs to the realm of system packages not local packages, but don't mistake this as me asking for such a "feature". :)
This would be a distro-specific check. namcap might actually do it. http://wiki.archlinux.org/index.php/Namcap#Files # file-in-non-standard-dir (warning) The following file is in a non-standard directory as defined by the FHS guidelines. The allowed directories are: bin/, etc/, usr/bin/, usr/sbin/, usr/lib, usr/include/, usr/share/, opt/, lib/, sbin/, srv/, var/lib/, var/opt/, var/spool/, var/lock/, var/state/, var/run/, var/log/.
BTW, I don't recall which devs added the splitpkg functionality, but I LOVE it! Thanks a million!
Allan broke^W did IT :)
participants (3)
-
Allan McRae
-
Jeff
-
Xavier