| 1 |
First, I like your idea of supporting a symlinked package model in |
| 2 |
portage. I think that would be a great addition, and I don't think it |
| 3 |
should be very hard. We also use a similar system at work. I wish |
| 4 |
portage ebuilds supported a $PREFIX variable so that ebuilds could be used |
| 5 |
to install into /usr/local (or wherever). |
| 6 |
|
| 7 |
For those who may be new to stow, et. al. An alternative to stow that I |
| 8 |
think has some advantages is the Encap Package Manager: epkg |
| 9 |
http://www.encap.org/epkg. It's written in C (rather than perl), and it |
| 10 |
supports more automated versioning. My intent is not to start a "this is |
| 11 |
better that that" war. Just wanted to give an alternative to those that |
| 12 |
are new to the concept. ;-) |
| 13 |
|
| 14 |
Brian |
| 15 |
|
| 16 |
|
| 17 |
> I agree, stow is cool and at work we use it to maintain our 12GB |
| 18 |
> /usr/local tree that is exported over nfs to our workstations. |
| 19 |
> Some drawbacks, however: |
| 20 |
> |
| 21 |
> - You have a slight speed loss because of the symlinking adding |
| 22 |
> extra lookups. Luckily, Linux has very good caching :) |
| 23 |
> |
| 24 |
> - Some packages hate it when you symlink stuff; e.g. sudo needs its |
| 25 |
> sudoers file to be a regular file. Granted, this is a configuration |
| 26 |
> file and as such may not need to be symlinked in a general gentoo |
| 27 |
> context, so this could be solved by just creating a regular file in |
| 28 |
> the |
| 29 |
> pkg_postinst. |
| 30 |
> |
| 31 |
> - stow -R can grind your server to a screeching halt if you have many |
| 32 |
> files. I'm sure this is solveable by rewriting the code a little, and |
| 33 |
> I don't know if recent versions have trouble with it since we don't |
| 34 |
> try it anymore ;) |
| 35 |
> |
| 36 |
> - You have a lot of symlinks in your /usr, which makes ls -l a bit less |
| 37 |
> attractive to look at. Of course, there's still ls -lL ;-) |
| 38 |
> |
| 39 |
> I've been considering nagging to drobbins about changing Portage so that |
| 40 |
> merging actually means |
| 41 |
> 'Copy package to /var/db/packages/<cat>/<pkg>/files/ and symlink |
| 42 |
> everything' and unmerging means 'remove the symlinks'. Portage would |
| 43 |
> then need a purge option to remove the package files altogether. |
| 44 |
> |
| 45 |
> This would have the advantage that you can always revert to a certain |
| 46 |
> version of a package with certainty, since no files are removed from the |
| 47 |
> previous package. And you see where a file comes from really quickly by |
| 48 |
> looking at the symlink, which is very useful. |
| 49 |
> |
| 50 |
> And actually, I think it would be possible to let portage optionally |
| 51 |
> have that feature, because the only thing it changes is where the files |
| 52 |
> are installed and what merge and unmerge do. All the rest would stay the |
| 53 |
> same. That way, people who want it can turn it on and the rest aren't |
| 54 |
> bothered. |
Archives