On Tue, 6 Aug 2013 21:33:02 +0100 Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> On Tue, 6 Aug 2013 16:22:48 -0400 > Alexis Ballier <aball...@gentoo.org> wrote: > > On Tue, 6 Aug 2013 20:44:57 +0100 > > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > > On Tue, 6 Aug 2013 15:31:14 -0400 > > > Alexis Ballier <aball...@gentoo.org> wrote: > > > > Well, ok, but this doesn't relate to what I was writing. > > > > Subslot, or slot emulators or whatever, in their current usage > > > > with := dependencies, are not fine grained enough for some use > > > > cases. Those cause regressions if used improperly. > > > > > > There is no regression. Previously, packages sometimes broke when > > > doing an upgrade. Now, packages do not break when doing an > > > upgrade. > > > > The regression is the useless rebuild. Without preserve-libs, > > packages break even more: cf the libc example. > > You can't claim a broken solution to be better than a working > solution. They're not yet comparable. What I claim is: - Preserve-libs is needed for extreme cases such as the libc or libs the compiler links to. - When used correctly, subslots provide a nice way to automate the rebuilds and correctly handle dependencies. - Current subslots and := deps do not provide all the required flexibility for real world packages. - Your proposal of not caring about it and introducing useless bloat is wrong. > > > > Your argumentation is basically 'Other parts are doing it wrong > > > > so it's ok to add some more to it'... We're back a dozen emails > > > > back, aren't we? > > > > > > It's not adding more to it. It's avoiding eliminating a tiny > > > portion of it. Even if you subscribe to the notion that > > > unnecessary rebuilds are a relevant problem, there's no point in > > > caring about the occasional unnecessary rebuild due to overly > > > strict dependencies when most unnecessary rebuilds are caused by > > > something else entirely. > > > > And here we go again... > > You've still not justified spending a massive amount of effort on > addressing a tiny fraction of unnecessary recompiles. What makes this > supposed problem in any way relevant? Why should we spend time > reducing 1% of the cost by 1%? You've still not done a serious analysis to back up these numbers. I'm pretty much convinced wrongly used subslot operators are now more than 50% of unnecessary recompile times. Feel free to prove me wrong, but you won't convince me by keeping repeating 'a tiny fraction of unnecessary recompiles'. Proper subslot operators is a one-time investment, reducing unnecessary compiles on the other parts likely require a constant investment over time, so in the long term, whatever the cost is, it is worth it. > > > > It was meant as an example and has nothing to do with dependency > > > > resolution. The above exercise is something extreme but that we > > > > have to solve; preserve-libs has proven to be correct enough. > > > > You have yet to show a correct, in your sense, solution. > > > > > > The correct solution is heavy slotting. And I'd hardly consider > > > "intermittently introduces invisible security holes and causes > > > unbootable systems" to be "correct enough"... > > > > There is no difference between heavy slotting and preserve-libs in > > this case. > > Yes there is: heavy slotting is only dependent upon a careful > developer, whereas preserve-libs relies upon voodoo that can go > horribly wrong. And also has the big advantage of providing an ancient outdated library in its proper slot so that it might be kept indefinitely.
