[gentoo-dev] Multislot dependencies

[gentoo-dev] Multislot dependencies

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 2509 bytes --]

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

Furthermore it is possible that a package "foo" which used one slot of
"bar" to build may also use a different slot on runtime (think of
plugins for a slotted app).

(list not necessarily conclusive)

Since this has (again) enough potential to result in a flamewar, I'd
like to point out what I think we should do/avoid:

What I think we should do now:
* Complete the list of problems/use cases
* Sort the cases by importance
* See that we can come up with a common solution to at least 60% of the
cases (yes, we may also actively decide to _not_ support certain cases,
but we have to be aware of them)
* Decide when it should be implemented, what is needed to implement it
and who's involved in that

What I think we should not discuss (right now):
* Which package manager has what implemented (remember: it's more
interesting right now _why_ it has been decided to do it like that)
* How "|| ( cat/bar:2 cat/bar:3 )" could be expressed in a simpler way.
This is pure syntactic sugar
* How the implementation should be done or what else it should include.
We should concentrate on "what is needed that the package manager devs
can implement it properly"

Thanks in advance,
Tiziano

-- 
-------------------------------------------------------
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin
E-Mail     : dev-zero@gentoo.org
GnuPG FP   : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Multislot dependencies

[Bernd Steinhauser]

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.

Regards,
Bernd

-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Multislot dependencies

[Tiziano Müller]

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

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

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



-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Multislot dependencies

[Bernd Steinhauser]

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.

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

-- 
gentoo-dev@lists.gentoo.org mailing list

[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@lists.gentoo.org mailing list

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@lists.gentoo.org mailing list

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

[Enrico Weigelt]

<big_snip>

Funny, how you all manage to make simple things complicated ;-o

I guess nobody considered an trivial solutions like an useflag ...


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Gilles Dartiguelongue]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

Le lundi 30 juin 2008 à 19:01 +0200, Enrico Weigelt a écrit :
> <big_snip>
> 
> Funny, how you all manage to make simple things complicated ;-o
> 
> I guess nobody considered an trivial solutions like an useflag ...

no, this is not the proper solution. Just consider how bad gtk/gtk2
useflag was and that was with only 1 package with 2 slots. Now think
about say db (berkeleydb) or gtkhtml (and I'm still probably overlooking
the most important point).
-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Tiziano Müller]

Gilles Dartiguelongue wrote:

> Le lundi 30 juin 2008 à 19:01 +0200, Enrico Weigelt a écrit :
>> <big_snip>
>> 
>> Funny, how you all manage to make simple things complicated ;-o
>> 
>> I guess nobody considered an trivial solutions like an useflag ...
> 
> no, this is not the proper solution. Just consider how bad gtk/gtk2
> useflag was and that was with only 1 package with 2 slots. Now think
> about say db (berkeleydb) or gtkhtml (and I'm still probably overlooking
> the most important point).
Hehe, that'd be "funny".

With python it already gets messy:

RDEPEND="python2.4? ( !python2.5 ( !python2.6? ( dev-lang/python:2.4 )
python2.6? ( dev-lang/python:2.6 ) ) python2.5? ( !python2.6? (
dev-lang/python:2.5 ) python2.6? ( dev-lang/python:2.6) ) ) python2.6? (
dev-lang/python:2.6 )

or something like that...


-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Enrico Weigelt]

* Gilles Dartiguelongue <eva@gentoo.org> schrieb:
> Le lundi 30 juin 2008 à 19:01 +0200, Enrico Weigelt a écrit :
> > <big_snip>
> > 
> > Funny, how you all manage to make simple things complicated ;-o
> > 
> > I guess nobody considered an trivial solutions like an useflag ...
> 
> no, this is not the proper solution. Just consider how bad gtk/gtk2
> useflag was and that was with only 1 package with 2 slots. 

Well, some of you might still remember what I said about gtk and
slots long time ago. Just to summarize my point:

* the use of slots should be MINIMIZED. IMHO, the kernel is one
  of the few valid uses, gtk is NOT (1.* and 2.* are *different* 
  packages and so should be treated differently). 

* at runtime an most packages need that variant/slot they were
  built for (and gtk1'ed package needs gtk-1.x, NOT gtk-2.* and
  vice versa)
  
* often the slots are just necessary because the upstream's 
  bad code design. IMHO, if a package doesn't have *clean* 
  dependency tree, it's simply not a package, but just a 
  bunch of code ;-P
  
> Now think about say db (berkeleydb) or gtkhtml (and I'm still 
> probably overlooking the most important point).

What's exactly the problem with that packages ?


BTW: maybe many things would be easier, if portage itself could
differenciate between source and binary packages, but that might
be a too big step ;-o


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
--
gentoo-dev@lists.gentoo.org mailing list

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

[Santiago M. Mola]

On Tue, Jul 1, 2008 at 2:47 PM, Enrico Weigelt <weigelt@metux.de> wrote:
>
> Well, some of you might still remember what I said about gtk and
> slots long time ago. Just to summarize my point:
>
> * the use of slots should be MINIMIZED. IMHO, the kernel is one
>  of the few valid uses, gtk is NOT (1.* and 2.* are *different*
>  packages and so should be treated differently).
>
> * at runtime an most packages need that variant/slot they were
>  built for (and gtk1'ed package needs gtk-1.x, NOT gtk-2.* and
>  vice versa)
>

This is not going to change. We already unified the gtk USE flag, we
have SLOT dependencies now, and, generally, prior discussion,
decisions and common practices shows that we're not going to follow
that path.

We are talking about multislot dependencies. At this point, your
arguments are noise. So, please, don't continue with these points in
this thread.

Thanks,
-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Multislot dependencies

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

On Sat, 28 Jun 2008 19:57:11 +0200
Tiziano Müller <dev-zero@gentoo.org> wrote:
> 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?

:= only makes sense when something is both a DEPEND and an RDEPEND.
Actual behaviour, for Paludis, is that it rewrites := deps to :=blah
when writing to VDB any time it can, and leaves anything it can't as :=
deps. Verifying sanity of := use is left to developers and the QA tool.

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

The only sensible thing you can do with multiple matches on := slots
(and ||=, if that route is taken) is to take the slot of the best
matching installed version, and require that ebuilds do that too. In
real world cases, this works just fine.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Re: Multislot dependencies

[Tiziano Müller]

Ciaran McCreesh wrote:

> On Sat, 28 Jun 2008 19:57:11 +0200
> Tiziano Müller <dev-zero@gentoo.org> wrote:
>> 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?
> 
> := only makes sense when something is both a DEPEND and an RDEPEND.
> Actual behaviour, for Paludis, is that it rewrites := deps to :=blah
> when writing to VDB any time it can, and leaves anything it can't as :=
> deps. Verifying sanity of := use is left to developers and the QA tool.
... and the spec.

> 
>> 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.
> 
> The only sensible thing you can do with multiple matches on := slots
> (and ||=, if that route is taken) is to take the slot of the best
> matching installed version, and require that ebuilds do that too. In
> real world cases, this works just fine.
> 
so, ebuilds should use best_version instead of has_version for example.
That's what I meant and what I miss in the kdebuild-1 spec :-)


-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

On Sat, 28 Jun 2008 23:41:17 +0200
Tiziano Müller <dev-zero@gentoo.org> wrote:
> > := only makes sense when something is both a DEPEND and an RDEPEND.
> > Actual behaviour, for Paludis, is that it rewrites := deps to :=blah
> > when writing to VDB any time it can, and leaves anything it can't
> > as := deps. Verifying sanity of := use is left to developers and
> > the QA tool.
>
> ... and the spec.

The spec's well defined. It just tells you how := works, not how to use
it in a sensible manner. Pretty much the same as for everything else.

> > The only sensible thing you can do with multiple matches on := slots
> > (and ||=, if that route is taken) is to take the slot of the best
> > matching installed version, and require that ebuilds do that too. In
> > real world cases, this works just fine.
> > 
> so, ebuilds should use best_version instead of has_version for
> example. That's what I meant and what I miss in the kdebuild-1
> spec :-)

Generally, it "just works", because packages are usually fairly good at
picking up the best installed version themselves anyway. But yes, if
you have to pass a version manually to a package, best_version is the
way to do it.

And no, that's not something that should be in the spec. The devmanual,
perhaps, although there's no kdebuild stuff in there just now.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Tiziano Müller]

Ciaran McCreesh wrote:

> On Sat, 28 Jun 2008 23:41:17 +0200
> Tiziano Müller <dev-zero@gentoo.org> wrote:
>> > := only makes sense when something is both a DEPEND and an RDEPEND.
>> > Actual behaviour, for Paludis, is that it rewrites := deps to :=blah
>> > when writing to VDB any time it can, and leaves anything it can't
>> > as := deps. Verifying sanity of := use is left to developers and
>> > the QA tool.
>>
>> ... and the spec.
> 
> The spec's well defined. It just tells you how := works, not how to use
> it in a sensible manner. Pretty much the same as for everything else.
Sorry, but I disagree.

> 
>> > The only sensible thing you can do with multiple matches on := slots
>> > (and ||=, if that route is taken) is to take the slot of the best
>> > matching installed version, and require that ebuilds do that too. In
>> > real world cases, this works just fine.
>> > 
>> so, ebuilds should use best_version instead of has_version for
>> example. That's what I meant and what I miss in the kdebuild-1
>> spec :-)
> 
> Generally, it "just works", because packages are usually fairly good at
> picking up the best installed version themselves anyway. But yes, if
> you have to pass a version manually to a package, best_version is the
> way to do it.

And what about a function to tell the PM explicitly which slot of a
dependency has been used (as an alternative)? Or should that decision
always be left to the PM? (that's something I'd expect to be in the PMS)


-- 
gentoo-dev@lists.gentoo.org mailing list