Re: [gentoo-dev] Stow (Was: Why the FHS can't be followed)

["Brian Webb" <webbb@desertscenes.net>]

First, I like your idea of supporting a symlinked package model in
portage.  I think that would be a great addition, and I don't think it
should be very hard.  We also use a similar system at work.  I wish
portage ebuilds supported a $PREFIX variable so that ebuilds could be used
to install into /usr/local (or wherever).

For those who may be new to stow, et. al.  An alternative to stow that I
think has some advantages is the Encap Package Manager: epkg
http://www.encap.org/epkg.  It's written in C (rather than perl), and it
supports more automated versioning.  My intent is not to start a "this is
better that that" war.  Just wanted to give an alternative to those that
are new to the concept. ;-)

Brian


> I agree, stow is cool and at work we use it to maintain our 12GB
> /usr/local tree that is exported over nfs to our workstations.
> Some drawbacks, however:
>
> - You have a slight speed loss because of the symlinking adding
>   extra lookups. Luckily, Linux has very good caching :)
>
> - Some packages hate it when you symlink stuff; e.g. sudo needs its
>   sudoers file to be a regular file. Granted, this is a configuration
> file and as such may not need to be symlinked in a general gentoo
> context, so this could be solved by just creating a regular file in
> the
>   pkg_postinst.
>
> - stow -R can grind your server to a screeching halt if you have many
>   files. I'm sure this is solveable by rewriting the code a little, and
> I don't know if recent versions have trouble with it since we don't
> try it anymore ;)
>
> - You have a lot of symlinks in your /usr, which makes ls -l a bit less
>   attractive to look at. Of course, there's still ls -lL ;-)
>
> I've been considering nagging to drobbins about changing Portage so that
> merging actually means
> 'Copy package to /var/db/packages/<cat>/<pkg>/files/ and symlink
> everything' and unmerging means 'remove the symlinks'. Portage would
> then need a purge option to remove the package files altogether.
>
> This would have the advantage that you can always revert to a certain
> version of a package with certainty, since no files are removed from the
> previous package. And you see where a file comes from really quickly by
> looking at the symlink, which is very useful.
>
> And actually, I think it would be possible to let portage optionally
> have that feature, because the only thing it changes is where the files
> are installed and what merge and unmerge do. All the rest would stay the
> same. That way, people who want it can turn it on and the rest aren't
> bothered.