1 |
On Thu, 31 Oct 2002 8:11 am, Jean-Michel Smith wrote: |
2 |
> On Tuesday 29 October 2002 07:23 am, Paul de Vrieze wrote: |
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 |
6 |
> > now do an emerge -u libfoo the old version is installed. But if |
7 |
> > libfoo-1.0 allready was installed it doesn't get installed. The |
8 |
> > installation of libfoo-1.0 is not complete though, because libfoo-1.1 |
9 |
> > overwrites many of its files. Now with an emerge clean libfoo-1.1 is |
10 |
> > removed, as a consequence libfoo-1.0 is crippled and libfoo-1.1 is |
11 |
> > removed. An emerge clean after the upgrade to libfoo-1.1 would have |
12 |
> > stopped this. This is so the reason that emerge now performs an |
13 |
> > autoclean. |
14 |
> |
15 |
> What about situations where you want to keep multiple versions of a shared |
16 |
> library (that is, after all, one of the nice features of UNIX over, say, |
17 |
> Windows)? For example, you may have software that is compiled against an |
18 |
> older, incompatible version of imlib (or worse, 3rd party binaries you |
19 |
> can't recompile). |
20 |
> |
21 |
> emerge clean nukes the old installation, and while the system is now no |
22 |
> longer crufty it is also incompatible with that application. I've seen |
23 |
> this kino (before the new version came out) and dvlib, for example, and I'm |
24 |
> sure there are other situations as well. |
25 |
> |
26 |
> Jean. |
27 |
|
28 |
Isn't that what slots are for? |
29 |
|
30 |
-- |
31 |
Jonathan Hunt (The Real Jonathan Hunt) <jhuntnz@×××××××××××××××××.net> |
32 |
Jabber at jhuntnz@××××××.sk |
33 |
"He is no fool who gives what he cannot keep to gain what he cannot lose." |
34 |
Jim Elliot |