1 |
On 07-09-2012 14:39:38 -0400, Ian Stakenvicius wrote: |
2 |
> I guess maybe i'm not following your example. To spell it out better, |
3 |
> here's what I'm understanding: |
4 |
> |
5 |
> bar-1.0 has (prior to slot-operators) an RDEPEND="app-cat/libfnord". |
6 |
> No version specified. As such, it'll build successfully against |
7 |
> either libfnord-1 or libfnord-2. Right now (as i understand it) a |
8 |
> downgrade from libfnord-2 to libfnord-1 would "break" bar-1.0 bot |
9 |
> revdep-rebuild would detect and fix it. |
10 |
|
11 |
right or portage would preserve libfnord-2's libs |
12 |
|
13 |
> sub-slots + slot-operators would alleviate what I just described, |
14 |
> auto-rebuilding bar (at least that's the theory; i've had some issues |
15 |
> getting portage to downgrade things even with regular slots so some |
16 |
> work on the implementation might be needed with this, dunno) |
17 |
> |
18 |
> *IF* on the other hand, you're referring to the case of libfnord-2.1 |
19 |
> downgrading to libfnord-2 , then yes I can see how bar-1.0 would be |
20 |
> broken and revdep-rebuild wouldn't fix it. However, as far as I |
21 |
> understand it, proper LTVERSIONing should mean that bar wouldn't break |
22 |
> as anything which would break bar on a libfnord-2 downgrade shouldn't |
23 |
> be used by bar in libfnord-2.1 -- ie, the differences would be |
24 |
> internal to libfnord and not directly used by bar. |
25 |
|
26 |
Well, yes and no. The no applies to the case where bar works around a |
27 |
missing function by e.g. implementing it itself, conditionally. A |
28 |
package maintainer might not have been aware of this, hence not |
29 |
expressed this in the dependencies (e.g. requiring the version that |
30 |
contains the missing function). |
31 |
Anyway, we should avoid downgrades of libraries, so no need to discuss |
32 |
this any further. It doesn't break more than it does already. |
33 |
|
34 |
|
35 |
-- |
36 |
Fabian Groffen |
37 |
Gentoo on a different level |