| 1 |
Hey there, |
| 2 |
|
| 3 |
On 2 Jul 2002, Fuper wrote: |
| 4 |
|
| 5 |
> On Tue, 2002-07-02 at 20:54, Luke Ravitch wrote: |
| 6 |
|
| 7 |
> Now, as for Stow -- I beat you up for not loving Stow! I may find some |
| 8 |
> drawbacks in the future that are not apparent to me now but it seems to |
| 9 |
> me that the tiny Stow script makes it possible to install, upgrade, and |
| 10 |
> remove software packages without depending on a database to track all of |
| 11 |
> the files. For example, I can answer the following questions without |
| 12 |
> reference to an rpm or dpkg (or portage) database: |
| 13 |
[...] |
| 14 |
|
| 15 |
I agree, stow is cool and at work we use it to maintain our 12GB |
| 16 |
/usr/local tree that is exported over nfs to our workstations. |
| 17 |
Some drawbacks, however: |
| 18 |
|
| 19 |
- You have a slight speed loss because of the symlinking adding |
| 20 |
extra lookups. Luckily, Linux has very good caching :) |
| 21 |
|
| 22 |
- Some packages hate it when you symlink stuff; e.g. sudo needs its |
| 23 |
sudoers file to be a regular file. Granted, this is a configuration file |
| 24 |
and as such may not need to be symlinked in a general gentoo context, so |
| 25 |
this could be solved by just creating a regular file in the |
| 26 |
pkg_postinst. |
| 27 |
|
| 28 |
- stow -R can grind your server to a screeching halt if you have many |
| 29 |
files. I'm sure this is solveable by rewriting the code a little, and I |
| 30 |
don't know if recent versions have trouble with it since we don't try it |
| 31 |
anymore ;) |
| 32 |
|
| 33 |
- You have a lot of symlinks in your /usr, which makes ls -l a bit less |
| 34 |
attractive to look at. Of course, there's still ls -lL ;-) |
| 35 |
|
| 36 |
I've been considering nagging to drobbins about changing Portage so that |
| 37 |
merging actually means |
| 38 |
'Copy package to /var/db/packages/<cat>/<pkg>/files/ and symlink everything' |
| 39 |
and unmerging means 'remove the symlinks'. Portage would then need a |
| 40 |
purge option to remove the package files altogether. |
| 41 |
|
| 42 |
This would have the advantage that you can always revert to a certain |
| 43 |
version of a package with certainty, since no files are removed from the |
| 44 |
previous package. And you see where a file comes from really quickly by |
| 45 |
looking at the symlink, which is very useful. |
| 46 |
|
| 47 |
And actually, I think it would be possible to let portage optionally have |
| 48 |
that feature, because the only thing it changes is where the files are |
| 49 |
installed and what merge and unmerge do. All the rest would stay the |
| 50 |
same. That way, people who want it can turn it on and the rest aren't |
| 51 |
bothered. |
| 52 |
|
| 53 |
Thoughts? |
| 54 |
|
| 55 |
Wout. |
Archives