[arch-general] install packages using links?
Hi, Whenever I install autotools-aware programs from source, they don't go into /usr/local as is customary, but into their own directory called /opt/<package>/<version>, and then files in /opt/<package>/<version>/{{s,}bin,man} etc. get symlinked into their counterparts in /usr/local. I am using spill[1] for this. Thus, for gpp-2.24, which is a preprocessor like cpp(1) sporting modifiable syntax, the result is: /usr/local/bin/gpp -> /opt/gpp/2.24/bin/gpp* /usr/local/man/man1/gpp.1 -> /opt/gpp/2.24/man/man1/gpp.1 The advantage is easy to see: you can always see what package some file belongs to, and removing a package is as simple as removing matching links and the installation directory. All files belonging to a package are in one place. spill(8) automates package installation and management, but this can be done manually as well. Would going this route for arch-linux packages be seen as an improvement? [1] http://www.rpcurnow.force9.co.uk/spill/ clemens PS: I originally sent this to arch-dev-public@, but obviously I can subscribe to that list while not qualified to post.
clemens fischer wrote:
Hi,
Whenever I install autotools-aware programs from source, they don't go into /usr/local as is customary, but into their own directory called /opt/<package>/<version>, and then files in /opt/<package>/<version>/{{s,}bin,man} etc. get symlinked into their counterparts in /usr/local. I am using spill[1] for this.
Thus, for gpp-2.24, which is a preprocessor like cpp(1) sporting modifiable syntax, the result is:
/usr/local/bin/gpp -> /opt/gpp/2.24/bin/gpp* /usr/local/man/man1/gpp.1 -> /opt/gpp/2.24/man/man1/gpp.1
The advantage is easy to see: you can always see what package some file belongs to, and removing a package is as simple as removing matching links and the installation directory. All files belonging to a package are in one place. spill(8) automates package installation and management, but this can be done manually as well.
Would going this route for arch-linux packages be seen as an improvement?
[1] http://www.rpcurnow.force9.co.uk/spill/
clemens
PS: I originally sent this to arch-dev-public@, but obviously I can subscribe to that list while not qualified to post.
Maybe GoboLinux is for you http://es.wikipedia.org/wiki/GoboLinux -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Gerardo Exequiel Pozzi wrote:
clemens fischer wrote:
/usr/local/bin/gpp -> /opt/gpp/2.24/bin/gpp* /usr/local/man/man1/gpp.1 -> /opt/gpp/2.24/man/man1/gpp.1 ...
Maybe GoboLinux is for you http://es.wikipedia.org/wiki/GoboLinux
Ah, I had forgotten about this distribution. Thanks for the pointer. clemens
On Sat, Jun 6, 2009 at 11:19 PM, clemens
fischer
The advantage is easy to see: you can always see what package some file belongs to,
pacman -Qo /path/to/file
and removing a package is as simple as removing matching links and the installation directory.
pacman -R pkgname
All files belonging to a package are in one place.
Well not quite the same, but pacman -Ql pkgname can be used to similar effect
Would going this route for arch-linux packages be seen as an improvement?
Let me get this straight, you propose to use one tool for package management (spill) together with another tool for package management (pacman)? Why? Admittedly symlinking ala spill is a nice and very KISS way of keeping track of files in your system, but since Arch already has a tool to do this, which keeps track of dependencies as well, why use a second one? Henning
Also, remaking all packages in the repos to do this? Erk. No thanks, Mr. Spillypants. -AT (PS. perhaps you folks haven't seen the Keith's Beer commercials where the guy keeps calling people Mr. Spillypants. Turns out that the actor for those commercials was later arrested for child porn and the company decided to stop showing those ads... ;)
Andrei Thorp wrote:
Also, remaking all packages in the repos to do this?
Where's the problem? The symlinking can be done at leisure, on routine updates. They are compatible. clemens
On Sun, Jun 7, 2009 at 11:31 AM, clemens
fischer
Andrei Thorp wrote:
Also, remaking all packages in the repos to do this?
Where's the problem? The symlinking can be done at leisure, on routine updates. They are compatible.
Well, as far as I can tell, the problem is that this requires the updating of the 4050 packages we have at the moment. All of them. By hand. For rather limited gain. And that's just in the official repos, not AUR, not Arch-games, not archlinux.fr, so on. -AT
-1. It's really not needed, pacman does plenty. And we should stick to the FHS when possible.
Daenyth Blank wrote:
-1. It's really not needed, pacman does plenty. And we should stick to the FHS when possible.
Keeping with norms is almost always good, but putting package files into their own directories and linking to them from the standard FHS places doesn't violate the FHS. Unless the FHS rules out symlinks. I cannot believe it does, though. clemens
Andrei Thorp wrote:
Well, as far as I can tell, the problem is that this requires the updating of the 4050 packages we have at the moment. All of them. By hand. For rather limited gain.
Well, you don't get it as far as I can tell. As all paths stay the same, _not one single package_ has to be updated. That's what I mean with "compatible". "/usr/bin/file" is still "/usr/bin/file", but it could be a symlink instead of a file. Look at the .so libraries: /lib/libcap.so -> libcap.so.2 /lib/libcap.so.2 -> libcap.so.2.16 /lib/libcap.so.2.16 Programs are already doing this all the time: /bin/bunzip2 -> bzip2 /bin/bzcat -> bzip2 /bin/bzip2 The symlinking itself is obviously not a problem. And having easier package management is a big gain. For many users, their linux distribution is a kernel plus the packages they like. I for one can appreciate not having to use "pacman" to find out what package some file belongs to. I even wrote my own wrapper giving it package globs just because "pacman" doesn't have them everywhere, using "ls" and "find" for some of the "-Q" and "-S" tasks would be a big plus IMO. clemens
On Mon, Jun 8, 2009 at 3:32 PM, clemens
fischer
Andrei Thorp wrote:
Well, as far as I can tell, the problem is that this requires the updating of the 4050 packages we have at the moment. All of them. By hand. For rather limited gain.
Well, you don't get it as far as I can tell. As all paths stay the same, _not one single package_ has to be updated. That's what I mean with "compatible". "/usr/bin/file" is still "/usr/bin/file", but it could be a symlink instead of a file. Look at the .so libraries:
/lib/libcap.so -> libcap.so.2 /lib/libcap.so.2 -> libcap.so.2.16 /lib/libcap.so.2.16
Programs are already doing this all the time:
/bin/bunzip2 -> bzip2 /bin/bzcat -> bzip2 /bin/bzip2
The symlinking itself is obviously not a problem. And having easier package management is a big gain. For many users, their linux distribution is a kernel plus the packages they like. I for one can appreciate not having to use "pacman" to find out what package some file belongs to. I even wrote my own wrapper giving it package globs just because "pacman" doesn't have them everywhere, using "ls" and "find" for some of the "-Q" and "-S" tasks would be a big plus IMO.
Things like this are a distro-wide decision. Some distros (notably, Gobo, which is one of my favorite distros, PS) do this, others do not. To me, this seems like unnecessary complication. pacman should be managing your installed software. If pacman does this, then it doesn't matter WHERE it's installed. IF you were doing things by hand, the symlink process makes sense (see GNU stow). As we're NOT doing this by hand, and have a tool already that manages installations and removal of software, adding this is just extra complexity which gains us nothing.
On Mon, Jun 8, 2009 at 1:32 PM, clemens
fischer
Andrei Thorp wrote:
Well, as far as I can tell, the problem is that this requires the updating of the 4050 packages we have at the moment. All of them. By hand. For rather limited gain.
Well, you don't get it as far as I can tell. As all paths stay the same, _not one single package_ has to be updated. That's what I mean with "compatible". "/usr/bin/file" is still "/usr/bin/file", but it could be a symlink instead of a file. Look at the .so libraries:
Okay, but how do those links get to the places they're supposed to be if you don't update packages to put them there? Anyway, I think there is a widely echoed polite "decent idea if we didn't already have all we need. No thank you". Cheers, -AT
Andrei Thorp wrote:
Okay, but how do those links get to the places they're supposed to be if you don't update packages to put them there?
Currently all files are there, no need to change that, it works. If any package is updated, the files would have to be replaced anyway, so put links to the actual places there. This is what I'm doing in /usr/local for self installed and local stuff. I have non-symlinked packages there and the newer symlink-style. There is no service disruption.
Anyway, I think there is a widely echoed polite "decent idea if we didn't already have all we need. No thank you".
Yes, I somehow came to the same conclusion 8-) There are many archlinux packages I don't care changing and I can use them as they are, for others, I have my symlinked installs in /usr/local. No problem. clemens
On Sat, Jun 06, 2009 at 04:05:56PM -0700, Andrei Thorp wrote:
Also, remaking all packages in the repos to do this? Erk. No thanks, Mr. Spillypants.
-AT
(PS. perhaps you folks haven't seen the Keith's Beer commercials where the guy keeps calling people Mr. Spillypants. Turns out that the actor for those commercials was later arrested for child porn and the company decided to stop showing those ads... ;)
Spilly Talker. ;) http://www.youtube.com/watch?v=H15xBHqPDZE
participants (7)
-
Aaron Griffin
-
Andrei Thorp
-
clemens fischer
-
Daenyth Blank
-
Gerardo Exequiel Pozzi
-
Henning Garus
-
Loui Chang