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