Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies

[Alexis Ballier]

On Tue, 6 Aug 2013 21:33:02 +0100
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote:

> On Tue, 6 Aug 2013 16:22:48 -0400
> Alexis Ballier <aballier@g.o> wrote:
> > On Tue, 6 Aug 2013 20:44:57 +0100
> > Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote:
> > > On Tue, 6 Aug 2013 15:31:14 -0400
> > > Alexis Ballier <aballier@g.o> 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.