1 |
On Tuesday 29 October 2002 07:23 am, Paul de Vrieze wrote: |
2 |
|
3 |
> The problem is downgrading. If you have had installed say libfoo-1.1. Now |
4 |
> the developers find out that libfoo-1.1 is seriously broken. As a |
5 |
> consequence, libfoo-1.1 is masked, and libfoo-1.0 is the newest. If you now |
6 |
> do an emerge -u libfoo the old version is installed. But if libfoo-1.0 |
7 |
> allready was installed it doesn't get installed. The installation of |
8 |
> libfoo-1.0 is not complete though, because libfoo-1.1 overwrites many of |
9 |
> its files. Now with an emerge clean libfoo-1.1 is removed, as a consequence |
10 |
> libfoo-1.0 is crippled and libfoo-1.1 is removed. An emerge clean after the |
11 |
> upgrade to libfoo-1.1 would have stopped this. This is so the reason that |
12 |
> emerge now performs an autoclean. |
13 |
|
14 |
What about situations where you want to keep multiple versions of a shared |
15 |
library (that is, after all, one of the nice features of UNIX over, say, |
16 |
Windows)? For example, you may have software that is compiled against an |
17 |
older, incompatible version of imlib (or worse, 3rd party binaries you can't |
18 |
recompile). |
19 |
|
20 |
emerge clean nukes the old installation, and while the system is now no longer |
21 |
crufty it is also incompatible with that application. I've seen this kino |
22 |
(before the new version came out) and dvlib, for example, and I'm sure there |
23 |
are other situations as well. |
24 |
|
25 |
Jean. |