[gentoo-dev] Re: Re: Multislot dependencies

[Tiziano Müller]

Bernd Steinhauser wrote:

> Tiziano Müller schrieb:
>> Bernd Steinhauser wrote:
>>
>>> Tiziano Müller schrieb:
>>>> Hi everyone
>>>>
>>>> I'd like to bring bug #229521 to your attention and see whether we can
>>>> come up with a solution for it.
>>>>
>>>> The problem:
>>>> A package "foo" depends on a slotted package "bar" _and_ more than one
>>>> slot of "bar" can satisfy this dependency.
>>>>
>>>> Why this is a problem:
>>>> If the dependency looks like one of the following:
>>>> * DEPEND=">=cat/bar-2"
>>>> * DEPEND="<=cat/bar-3"
>>>> * DEPEND="|| ( cat/bar:2 cat/bar:3 )
>>>> then the package manager doesn't know after building "foo" which slot
>>>> of "bar" has been used to build "foo". On the other hand might this
>>>> information be needed to debug problems with package "foo".
>>>>
>>>> The problem gets even worse as soon as RDEPEND comes in:
>>>> (assuming the same examples from above but with RDEPEND)
>>>> * The package manager currently doesn't record which slot has been used
>>>> and can't therefore track whether the user will destroy something in
>>>> case he uninstalls one of the slots of "bar"
>>>> * The package manager can't sanely consider whether an update for a
>>>> slot is actually needed
>>> There is a section in PMS, that tries to address this.
>>>
>>> =================
>>> Slot Dependencies
>>> A named slot dependency consists of a colon followed by a slot name. A
>>> specification with
>>> a named slot dependency matches only if the slot of the matched package
>>> is equal to the slot
>>> specified. If the slot of the package to match cannot be determined
>>> (e.g. because it is not a
>>> supported EAPI), the match is treated as unsuccessful.
>>> An operator slot dependency consists of a colon followed by one of the
>>> following operators:
>>> * Indicates that any slot value is acceptable. In addition, for runtime
>>> dependencies, indicates
>>> that the package will not break if the matched package is uninstalled
>>> and replaced by a
>>> different matching package in a different slot.
>>> = Indicates that any slot value is acceptable. In addition, for runtime
>>> dependencies, indicates
>>> that the package will break unless a matching package with slot equal to
>>> the slot of the
>>> best installed version at the time the package was installed is
>>> available. To implement the equals slot operator, the package manager
>>> will need to store the slot of the
>>> best installed version of the matching package. The package manager may
>>> do this by appending
>>> the appropriate slot after the equals sign when saving the package?s
>>> dependencies. This syntax
>>> is only for package manager use and must not be used by ebuilds.
>>> =================
>>>
>>> So, if you go with that, the dependency would look like this:
>>> DEPEND=">=cat/bar-2:="
>>>
>>> That means, that it accepts any slot of versions above version 2, but
>>> restricts it to the slot it has been built against, at runtime.
>>> The combination of >= and := might look a bit ugly, so maybe it might
>>> indeed be useful to specify a way to provide a list of slots.
>>> But it would work in most cases.
>>
>> hmm, this is kdebuild-1...
> Indeed, but it is a proposal.
>
>> I miss two things here:
>> a) What happens in case of DEPEND="", RDEPEND=">=cat/bar-2:=" ? Is that
>> defined? If yes, what does it mean? If not, what shall be the package
>> managers behaviour?
> I don't think, that RDEPEND matters here.
> If a dep is not in DEPEND, that means, that it doesn't affect the build
> process of the package. So in case the dep spec matches more than one
> slot, the package should be able to use both without a rebuild.
> (Which means, that the package manager can switch the dep.)
> If changing the slot would mean, that a rebuild is required, then the
> dep affects the package at build time and should be in DEPEND.
Oh, my point is much simpler:
The kdebuild-1 spec says: "[...] that the package will break unless a
matching package with slot equal to the slot of the best installed version
at the time the package was installed is available."
But: RDEPEND doesn't have to be evaluated before installing the package and
DEPEND doesn't contain this package. So, there is no record of such a
package. What now?

>
>> b) It is not said that a package depending on "|| ( cat/bar:2 cat/bar:3
>> )" then really uses cat/bar:3 if available, it might as well use
>> cat/bar:2 for one reason or another. It might be clearer if we have slots
>> named "stable", "unstable". In such a case a package depending on cat/bar
>> might decided to use cat/bar:stable if available instead of
>> cat/bar:unstable. So, the spec should either state that the package must
>> use the best matching version or we need another way for such cases, like
>> a function to explicitly tell the pm which slot has been used.
> Not sure if that is a good idea, because you would expect, that those
> slot assignments (assuming you mean stable and unstable as list of
> slots) get changed if a different slot is now "stable" and that would
> break previous assignments.
> BTW, you can already name a slot unstable-2 or similar. KDE 4.0 has slot
> kde-4, for example.
I know :-)

> Regarding the || ( cat/bar:2 cat/bar:3 ) construction, if a package
> manager chooses one out of the two, it should restrict the package to
> this dep at runtime.
Hmm, this is the point: What happens if the package chooses cat/bar:2 to
link against and the package manager records cat/bar:3 since it assumes
this is the better match? Is it it allowed to do the following (it's an
example):

DEPEND="|| ( sys-libs/db:4.5 sys-libs/db:4.6 )"

pkg_setup() {
    DB_VER=""
    # both major versions work but prefer 4.5 if available
    has_version "sys-libs/db:4.5" && DB_VER="4.5"
}

Questions:
a) should DEPEND be valid?
b) will has_version evaluate to true?
c) how will the pm know that the package chose sys-libs/db:4.5
d) should this be allowed or not?
e) if yes, can the package tell the pm about the choice?

> Not sure how the several package managers handle this, tbh.

>> I think that problem a) is a bit nasty, but it might become better if
>> we'd split the dependency variables into DEPEND, RDEPEND, C(OMMON_)DEPEND
>> (where the last one would be used for packages needed at compile time and
>> runtime).
> I would rather vote for labels, which clear the whole dependency thing
> up a bit and doesn't splatter them over several vars.
> Unfortunately that is not compatible with the current way of specifying
> deps.

Labels as proposed by kdebuild-1 are only for PDEPEND, right?


-- 
gentoo-dev@l.g.o mailing list