On Mon, 5 Aug 2013 19:13:06 +0100 Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > > 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?
No, but this sounds like a tradeoff between useless subslots for virtuals and more general considerations... If you want something that works in every case it'll obviously be more complicated. > > > > > 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. No, this assumes it is done correctly and independently of subslots: soname change iff ABI is not backward compatible. A soname change requires the rebuild, regardless of the symbols used. > > > 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. Again, symbols have nothing to do here. Since you have poor control on overlays and absolutely zero control on locally built packages, the only sane assumption is that all symbols are used. > > > 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. And then when a package has various libraries, one being very unstable abi-wise and the others stable, it seems much more sane not to := depend on said package if you only use the stable ones when the subslot clearly refers to the unstable abi library. > > > 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. I don't see how current subslots improve a) and b) is just a matter of UI defaults...
