1 |
Jean-Michel Smith <jsmith@××××.com>, on Wed Oct 30, 2002 [01:11:10 PM] said: |
2 |
> |
3 |
> What about situations where you want to keep multiple versions of a shared |
4 |
> library (that is, after all, one of the nice features of UNIX over, say, |
5 |
> Windows)? For example, you may have software that is compiled against an |
6 |
> older, incompatible version of imlib (or worse, 3rd party binaries you can't |
7 |
> recompile). |
8 |
> |
9 |
> emerge clean nukes the old installation, and while the system is now no longer |
10 |
> crufty it is also incompatible with that application. I've seen this kino |
11 |
> (before the new version came out) and dvlib, for example, and I'm sure there |
12 |
> are other situations as well. |
13 |
> |
14 |
> Jean. |
15 |
|
16 |
Hi; |
17 |
|
18 |
I believe the SLOT ebuild variable is for just this |
19 |
situation. I personally have quite a few packages where old and |
20 |
new libraries coexist, and 'emerge clean' leaves them alone. |
21 |
'emerge prune' will nuke all but the latest version |
22 |
of a package, I believe. (and perhaps older stuff that was |
23 |
unSLOTed.) |
24 |
So, I would consider it a bug if 'clean' nuked an old |
25 |
version of a package that can coexist with newer versions via |
26 |
a SLOT... |
27 |
|
28 |
Paul |
29 |
set@×××××.com |