On Mon, 5 Aug 2013 18:28:54 +0100 Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> On Mon, 5 Aug 2013 12:51:48 -0400 > Alexis Ballier <aball...@gentoo.org> wrote: > > > Not really. There's a tradeoff between dependencies that are > > > occasionally too strict, and dependencies that are horribly > > > complicated (see "subslot dictionaries"). > > > > having a way to express 'my subslot is the one of my provider' > > doesnt seem overly complicated > > Unfortunately things that "don't seem" to be complicated sometimes are > complicated. We haven't established whether that's the case here. In > particular, we don't have any notion of "providers" currently, s/currently/anymore/ > and > it's not clear such a concept makes sense as-is. We haven't worked > out what happens in a || ( a b !c ) case where a, b and c are all > installed, for example. subslot = concatenation of the subslots of all (positive? if it makes sense) dependencies; updated when said dependencies get their subslot changed. this seems to fit well for a virtual and should be in line with what one would get with old style virtuals in mind. > > > So all this fuss over "unnecessary compiles" is misplaced. Gentoo > > > simply isn't the right distribution to use if minimising compile > > > time is a goal. > > > > two wrongs do not make one right... esp. when the 'wrong' at hand > > can be easily avoided... > > We've not established that it's "easy". you don't believe it is; and the first part still applies, meaning we should avoid to do the wrong thing just because there are other areas where we got it wrong. > > > > 'horrible breakage' is mitigated by preserve-libs and running > > > > @preserved-rebuild as soon as possible has the same end result > > > > avoiding useless rebuilds. > > > > > > But preserve-libs introduces breakages and security holes. The > > > point of slot operator dependencies is to replace that with a > > > reliable feature that doesn't rely upon guesswork and voodoo. > > > > not more than subslots, per pms: > > The sub-slot is used to represent cases in which an upgrade to a > > new version of a package with a different sub-slot may require > > dependent packages to be rebuilt. > > > > so, per spec, it isnt reliable either since the spec does not > > enforce rebuilds as soon as possible, heck, it doesnt even enforces > > rebuilds... (may vs must + when) > > You are misreading that statement. The "may" is there because even in > cases where there is an ABI break, some dependent packages may not > require recompiling because they may not be using the full ABI. The > "may" means developers are not prohibited from changing subslots in > the case where there exists a package which will not break. how can one know if that 'may' applies ? > Also, "as soon as possible" doesn't come into it anywhere. It's not > even a well defined requirement. read it differently then: foo has := dependencies that changed their subslot after foo has been installed. Is a DEPEND on foo considered satisfied or should foo be rebuilt before ? > Also also, the spec generally avoids wordings that prohibit the > package manager from breaking things (partly because Portage doesn't > properly enforce dependencies, partly because prohibiting the user > from breaking things if they really want to is not the Gentoo way). > The spec prefers to state things in terms of what can be relied upon > to work. Supposing we are dealing with shared libraries only, how is that an improvement over preserve-libs ?
