On Mon, Jun 8, 2009 at 3:32 PM, clemens fischer<ino-news@spotteswoode.dnsalias.org> wrote:
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.