On Mon, 5 Aug 2013 13:58:49 -0400 Alexis Ballier <aball...@gentoo.org> wrote: > > 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/
Well the old definition won't do what you want... > > 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. Have you established that that's the correct behaviour in every (or any) case where these will be used? > > > > 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. I disagree with your assertion that the occasional unnecessary rebuild is "wrong", when one considers the cost of avoiding it. Do you really want developers to have to manually check and specify exactly which symbols their package uses from every single slottable dependency? Such a list could easily run to thousands of entries per dependency. > > 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 ? Package manglers are expected to assume that it could apply. Ebuild developers are not expected to guarantee that it will, since providing that guarantee is very very difficult and would require knowledge of exactly which symbols are used by every dependent of a package. > > 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 ? That's covered by the spec. Basically, ignoring many of the complications that make dependency resolution such a pain, for a dependency to be usable, all its dependencies must be usable. The "may" there is simply there to avoid prohibiting developers from doing a subslot bump when it could turn out not to be necessary after all. > > 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 ? We aren't dealing with shared libraries only. Even if we were, a) shared libraries have dependencies upon things that are not shared libraries, like text files, and b) subslots don't facilitate using an old, insecure shared library to generate content. -- Ciaran McCreesh
signature.asc
Description: PGP signature
