Re: [gentoo-dev] Re: Re: Multislot dependencies

[Bernd Steinhauser]

Tiziano Müller schrieb:
> 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?
tbh, I don't get what you are on about.
The slot restrictions only matter in cases where a rebuild what be 
required, because the package would break, if you change the installed 
slot. But in that case the dep affects runtime and should be in DEPEND.
For runtime-only deps, the package manager should be allowed to change 
the slot, if multiple slots are allowed.

>> 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?
That would (in my opinion) a bug in the ebuild.
You handle only the case where db:4.5 is available and not the other case.
Nevertheless, I think what we might need here is something like a reference.
For example, there could be a tag introduced.
||[db] ( sys-libs/db:4.5 sys-libs/db:4.6 )

and then:
if_pulled db[1] && DB_VER="4.5"
if_pulled db[2] && DB_VER="4.6"

Then, if the package manager restricts || ( ) constructions to the 
selected dep, you would have a way to ensure, that the correct dep is 
installed.
Tbh, the whole "check-if-a-package-(version)-is-installed" thing is a 
bit of a hack.

>>> 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?
Yes, because kdebuild-1 uses the gentoo way of specifying deps (DEPEND, 
RDEPEND etc.).
But labels in general aren't restricted to PDEPEND.
Actually labels (if fully implemented) obsolete DEPEND, RDEPEND etc.
See https://bugs.gentoo.org/show_bug.cgi?id=201499#c21 for an example.

The result is, that it is better readable and gives more possibilities.
-- 
gentoo-dev@l.g.o mailing list