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

[Alexis Ballier]

On Mon, 5 Aug 2013 18:28:54 +0100
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote:

> On Mon, 5 Aug 2013 12:51:48 -0400
> Alexis Ballier <aballier@g.o> wrote:
> > > Not really. There's a tradeoff between dependencies that are
> > > occasionally too strict, and dependencies that are horribly
> > > complicated (see "subslot dictionaries").
> >
> > having a way to express 'my subslot is the one of my provider'
> > doesnt seem overly complicated
>
> 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/

> 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.

this seems to fit well for a virtual and should be in line with what
one would get with old style virtuals in mind.

> > > 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.

> > > > 'horrible breakage' is mitigated by preserve-libs and running
> > > > @preserved-rebuild as soon as possible has the same end result
> > > > avoiding useless rebuilds.
> > >
> > > But preserve-libs introduces breakages and security holes. The
> > > point of slot operator dependencies is to replace that with a
> > > reliable feature that doesn't rely upon guesswork and voodoo.
> >
> > not more than subslots, per pms:
> >  The sub-slot is used to represent cases in which an upgrade to a
> > new version of a package with a different sub-slot may require
> > dependent packages to be rebuilt.
> >
> > so, per spec, it isnt reliable either since the spec does not
> > enforce rebuilds as soon as possible, heck, it doesnt even enforces
> > rebuilds... (may vs must + when)
>
> 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 ?

> 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 ?

> 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 ?