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

[Alexis Ballier]

On Tue, 6 Aug 2013 19:25:15 +0100
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote:

> On Tue, 6 Aug 2013 14:12:06 -0400
> Alexis Ballier <aballier@g.o> wrote:
> > On Tue, 6 Aug 2013 18:41:59 +0100
> > Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote:
> > > On Tue, 6 Aug 2013 13:05:07 -0400
> > > Alexis Ballier <aballier@g.o> wrote:
> > > > 'occasional unnecessary rebuild' is a big deal since subslots
> > > > introduce this regression...
> > >
> > > Er, no. Subslots just simplify the way accurate slot dependencies
> > > are expressed. That's all they are: an alternative to having a
> > > larger number of (full) slots plus blockers between some of those
> > > slots.
> >
> > hmmm... no ?
>
> Er, yes. You may be confusing subslots and :=/:* dependencies, which
> are a different feature.

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's an easy fix for that: split the package up.
> > > >
> > > > Great, please start submitting patches at our thousands of
> > > > upstreams so that their packages can be split properly.
> > >
> > > You don't need to patch anything... You just make poppler-stable
> > > and poppler-dodgy ebuilds.
> >
> > And you need to patch it to do it properly.
>
> You just make the ebuilds install different bits. In effect you
> emulate a simple subset of how parts would do it.

Which needs patching to be done properly... unless you are suggesting
to build it twice and throw away whats not needed just to workaround
subslots limitations.


> > Or you can do parts/subpackages or subslot dictionaries to express
> > that.
>
> Realistically, parts will never get implemented in Portage. Subslot
> dictionaries might be, if anyone ever figures out what they're
> supposed to be, but they're a heavy price for package developers to
> pay. The question under discussion is whether it's a price worth
> paying to avoid an occasional unnecessary rebuild. Since users do far
> more unnecessary rebuilds for other reasons anyway, and reducing CPU
> usage has never been a goal for Gentoo, I'm not convinced it's worth
> caring about.


Meanwhile, there's preserve-libs :)

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?


> > > > Exercise: Try to update a FreeBSD 6 system (libc.so.6) to a
> > > > FreeBSD 7 system (libc.so.7) without some kind of preserve-libs
> > > > mechanism. Been there, done that. The flaws of preserve-libs
> > > > show up but it maintains a half working system all the way long
> > > > that allows you to finish the update.
> > >
> > > There is no "half working". Something is either correct or it
> > > isn't.
> >
> > Sometimes there is no 'correct'. You are probably using every day
> > programs that use heuristics/approximations to solve NP-hard or
> > undecidable problems in a 'correct enough' way.
>
> Dependency resolution is at least NP hard, and we're still solving it
> exactly. But you're confusing approximations and feasibility here.

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.