[arch-general] install packages using links?

[Aaron Griffin]

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