[gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Tom Wijsman]

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

Hello fellow developers

== Situation ==

When specifying a dependency like cat/pkg it will default to cat/pkg:*
which is defined in `man 5 ebuild` as:

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

This default reflects different behavior than what we use slots for,
besides allowing side-by-side installations we rather use it to
specifically depend on a new major version. (eg. dev-libs/glib).

Let's say I want to a add a new major version of cat/pkg to the Portage
tree, introducing it in the same SLOT="0" isn't an option. This gives
us two options, one is SLOT="2", the other is to create cat/pkg2 or so.

Creating a new SLOT is the most sane thing going forward; but, as the
default (:*) depends on any SLOT, this needs a half thousand commits to
fix up reverse dependencies. Thus, instead a new package is made. [1]

When our defaults force us down such path, that can't be good and it
affects the quality of our Portage tree; so, this makes me wonder, can
we change the default from :* to :0? What do you think?

 [1] https://bugs.gentoo.org/show_bug.cgi?id=493652
     "media-libs/libsdl2: should be a SLOT=2 of media-libs/libsdl"

== Task ==

If we agree we do this; in order to change :* to :0, we need to change
the PMS to cover this change and implement it in the package managers.

Before we do that, we need to evaluate how practical this is to apply.
While we are trying to fix the default behavior, what would changing
the default from :* to :0 break?

One thing that directly comes to mind is that dependencies that have no
SLOT="0" ebuild present would need us to manually specify a specific
SLOT; given that this is a not so common situation, the amount of
commits needed here is low.

Another thing that comes to mind is that we need to check what to do
with packages were the highest available version does not belong to
SLOT="0"; technically, restricting these to SLOT="0" will not cause
breakage, it might however cause some blockers. We'll have to look
closer into how we can alleviate this result.

Is there anything else we need to take into account?

== Summary ==

Situation:

    Defaulting to :* on SLOT-less dependencies makes it hard to add a
    new SLOT to a package, using :0 instead would not make this a
    problem and not require to fix up all reverse dependencies.

Task:

    Check results, correct some exceptions, update PMS, implement it.

Thank you in advance for participating in this discussion.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

[gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Tom Wijsman]

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

Hello fellow developers

== Situation ==

When specifying a dependency like cat/pkg it will default to cat/pkg:*
which is defined in `man 5 ebuild` as:

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

This default reflects different behavior than what we use slots for,
besides allowing side-by-side installations we rather use it to
specifically depend on a new major version. (eg. dev-libs/glib).

Let's say I want to a add a new major version of cat/pkg to the Portage
tree, introducing it in the same SLOT="0" isn't an option. This gives
us two options, one is SLOT="2", the other is to create cat/pkg2 or so.

Creating a new SLOT is the most sane thing going forward; but, as the
default (:*) depends on any SLOT, this needs a half thousand commits to
fix up reverse dependencies. Thus, instead a new package is made. [1]

When our defaults force us down such path, that can't be good and it
affects the quality of our Portage tree; so, this makes me wonder, can
we change the default from :* to :0? What do you think?

 [1] https://bugs.gentoo.org/show_bug.cgi?id=493652
     "media-libs/libsdl2: should be a SLOT=2 of media-libs/libsdl"

== Task ==

If we agree we do this; in order to change :* to :0, we need to change
the PMS to cover this change and implement it in the package managers.

Before we do that, we need to evaluate how practical this is to apply.
While we are trying to fix the default behavior, what would changing
the default from :* to :0 break?

One thing that directly comes to mind is that dependencies that have no
SLOT="0" ebuild present would need us to manually specify a specific
SLOT; given that this is a not so common situation, the amount of
commits needed here is low.

Another thing that comes to mind is that we need to check what to do
with packages were the highest available version does not belong to
SLOT="0"; technically, restricting these to SLOT="0" will not cause
breakage, it might however cause some blockers. We'll have to look
closer into how we can alleviate this result.

Is there anything else we need to take into account?

== Summary ==

Situation:

    Defaulting to :* on SLOT-less dependencies makes it hard to add a
    new SLOT to a package, using :0 instead would not make this a
    problem and not require to fix up all reverse dependencies.

Task:

    Check results, correct some exceptions, update PMS, implement it.

Thank you in advance for participating in this discussion.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Michał Górny]

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

Dnia 2013-12-08, o godz. 17:56:12
Tom Wijsman <TomWij@gentoo.org> napisał(a):

> Hello fellow developers
> 
> == Situation ==
> 
> When specifying a dependency like cat/pkg it will default to cat/pkg:*
> which is defined in `man 5 ebuild` as:
> 
>     * 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.
> 
> This default reflects different behavior than what we use slots for,
> besides allowing side-by-side installations we rather use it to
> specifically depend on a new major version. (eg. dev-libs/glib).
> 
> Let's say I want to a add a new major version of cat/pkg to the Portage
> tree, introducing it in the same SLOT="0" isn't an option. This gives
> us two options, one is SLOT="2", the other is to create cat/pkg2 or so.
> 
> Creating a new SLOT is the most sane thing going forward; but, as the
> default (:*) depends on any SLOT, this needs a half thousand commits to
> fix up reverse dependencies. Thus, instead a new package is made. [1]
> 
> When our defaults force us down such path, that can't be good and it
> affects the quality of our Portage tree; so, this makes me wonder, can
> we change the default from :* to :0? What do you think?
> 
>  [1] https://bugs.gentoo.org/show_bug.cgi?id=493652
>      "media-libs/libsdl2: should be a SLOT=2 of media-libs/libsdl"
> 
> == Task ==
> 
> If we agree we do this; in order to change :* to :0, we need to change
> the PMS to cover this change and implement it in the package managers.
> 
> Before we do that, we need to evaluate how practical this is to apply.
> While we are trying to fix the default behavior, what would changing
> the default from :* to :0 break?

Packages that don't have SLOT=0 :). I was wondering about this some
time ago and this is where I stopped. You can't simply assume every
single package will have SLOT=0 as the default.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 728 bytes --]

Am Sonntag, 8. Dezember 2013, 17:56:12 schrieb Tom Wijsman:
> 
> When our defaults force us down such path, that can't be good and it
> affects the quality of our Portage tree; so, this makes me wonder, can
> we change the default from :* to :0? What do you think?
> 

I see the point, but I have my doubts on retroactively changing things.
(It's a global change where we would have to be very very very careful 
regarding interactions with eclasses and so on.)

How about changing this in the next EAPI instead?

E.g., in EAPI=6, if no slot dependency is given in a dependency specification, 
default to :0 

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Pacho Ramos]

El dom, 08-12-2013 a las 18:19 +0100, Andreas K. Huettel escribió:
> Am Sonntag, 8. Dezember 2013, 17:56:12 schrieb Tom Wijsman:
> > 
> > When our defaults force us down such path, that can't be good and it
> > affects the quality of our Portage tree; so, this makes me wonder, can
> > we change the default from :* to :0? What do you think?
> > 
> 
> I see the point, but I have my doubts on retroactively changing things.
> (It's a global change where we would have to be very very very careful 
> regarding interactions with eclasses and so on.)
> 
> How about changing this in the next EAPI instead?
> 
> E.g., in EAPI=6, if no slot dependency is given in a dependency specification, 
> default to :0 
> 
> -- 
> 
> Andreas K. Huettel
> Gentoo Linux developer 
> dilfridge@gentoo.org
> http://www.akhuettel.de/
> 

Other option I have sometimes consider is to force people to specify the
slot dependency on a newer eapi -> if a package is working for any slot,
specify :*, if not, specify the slot that it needs. That way, this kind
of problems would be much less frequent than currently

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Tom Wijsman]

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

On Sun, 08 Dec 2013 18:26:25 +0100
Pacho Ramos <pacho@gentoo.org> wrote:

> El dom, 08-12-2013 a las 18:19 +0100, Andreas K. Huettel escribió:
> > Am Sonntag, 8. Dezember 2013, 17:56:12 schrieb Tom Wijsman:
> >
> > > When our defaults force us down such path, that can't be good and
> > > it affects the quality of our Portage tree; so, this makes me
> > > wonder, can we change the default from :* to :0? What do you
> > > think?
> > 
> > How about changing this in the next EAPI instead?
> > 
> > E.g., in EAPI=6, if no slot dependency is given in a dependency
> > specification, default to :0 
> 
> Other option I have sometimes consider is to force people to specify
> the slot dependency on a newer eapi -> if a package is working for
> any slot, specify :*, if not, specify the slot that it needs. That
> way, this kind of problems would be much less frequent than currently

Given that the retroactive change I suggest causes a lot of complexity;
changing it on the next EAPI indeed sounds like one way to go, the
alternative is to make it a suggestive guideline or policy and cover
it as a QA check in repoman.

That QA check could throw a warning when a dependency has no slot.

--
PS: Sorry for sending the thread mail twice, IMAP timed out; since
this is the second time that this happened, I'll pay more attention.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Rich Freeman]

On Sun, Dec 8, 2013 at 12:46 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>
> Given that the retroactive change I suggest causes a lot of complexity;
> changing it on the next EAPI indeed sounds like one way to go, the
> alternative is to make it a suggestive guideline or policy and cover
> it as a QA check in repoman.
>
> That QA check could throw a warning when a dependency has no slot.

I think we're better off with defaulting to slot 0 rather than
erroring/warning if no slot is specified.  Otherwise we're basically
going to have to modify every ebuild in the tree to add the :0 (unless
there is no warning when only slot 0 exists, but then another slot
could be added at any time and what is the behavior then?).

Or we could do both - we could define EAPI 6 as having :0 be the
default slot behavior, and we could have repoman offer soft warnings
on earlier EAPIs if there is no explicit slot.

(I'd even suggest making the default :0= except that there is no way
to override that as we defined not depending on a subslot as the
absence of any operator and not a different operator that is simply
defaulted.)

Rich

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Ulrich Mueller]

>>>>> On Sun, 8 Dec 2013, Andreas K Huettel wrote:

> How about changing this in the next EAPI instead?

> E.g., in EAPI=6, if no slot dependency is given in a dependency
> specification, default to :0

PMS just provides a mechanism, but doesn't prefer one SLOT value over
another. Such a change would introduce policy into PMS which is not
the right way to go.

If a dependency on a specific SLOT value is needed then it should be
explicitly specified in the ebuild.

Ulrich

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Rich Freeman]

On Sun, Dec 8, 2013 at 2:14 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>
> PMS just provides a mechanism, but doesn't prefer one SLOT value over
> another. Such a change would introduce policy into PMS which is not
> the right way to go.

Sure it does - it defaults to :* when :* was never specified. I don't
see how defaulting to :0= is a "policy" any more than :* is.

>
> If a dependency on a specific SLOT value is needed then it should be
> explicitly specified in the ebuild.

Honestly, I think this is kind of like saying that garbage collection
is useless because programmers should just correctly free anything
they create exactly once.

If maintainers were generally giving careful thought to slots in
dependencies then we wouldn't have packages that stick the slot in the
package name instead.  Sure, we can just ban packages like these and
force everybody to fix all the breakage that results (which in theory
should never have existed), but it seems better to me to try to make
the best default the default.

I guess we could just ban any non-explicit slot version dependency (ie
90% of our current dependency atoms are now invalid), but that doesn't
really seems a bit like programming in Ada.  :)

Rich

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Ciaran McCreesh]

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

On Sun, 8 Dec 2013 14:39:39 -0500
Rich Freeman <rich0@gentoo.org> wrote:
> On Sun, Dec 8, 2013 at 2:14 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
> > PMS just provides a mechanism, but doesn't prefer one SLOT value
> > over another. Such a change would introduce policy into PMS which
> > is not the right way to go.
> 
> Sure it does - it defaults to :* when :* was never specified. I don't
> see how defaulting to :0= is a "policy" any more than :* is.

SLOT=0 isn't special in PMS these days. (Historically it was. Now SLOT
is mandatory, and it doesn't default to 0.)

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Ulrich Mueller]

>>>>> On Sun, 8 Dec 2013, Rich Freeman wrote:

> Sure it does - it defaults to :* when :* was never specified. I don't
> see how defaulting to :0= is a "policy" any more than :* is.

Defaulting to :* is just the long term behaviour from EAPIs 0 to 4
when no slot operator was specified. This is consistent with what we
haved for versioned dependencies. When you don't specify a version,
then all versions are good. Similarly, when you don't specify a slot,
then all slots are good.

Our rules of slot/subslot dependencies and slot operators are just
complicated enough, so I really would dislike complicating them even
more by having an EAPI dependent default. In addition, from a package
manager view there is nothing special at all about slot 0, so there's
no reason to prefer it over other values.

Ulrich

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Tom Wijsman]

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

On Sun, 8 Dec 2013 20:14:47 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Sun, 8 Dec 2013, Andreas K Huettel wrote:
> 
> > How about changing this in the next EAPI instead?
> 
> > E.g., in EAPI=6, if no slot dependency is given in a dependency
> > specification, default to :0
> 
> PMS just provides a mechanism, but doesn't prefer one SLOT value over
> another.

The PMS describes package manager behavior required to support an
ebuild repository. If I read the PMS correctly, SLOT-less dependencies
have undefined behavior; this makes it so that if you have a different
package manager using the same ebuild repository, it could interpret
the dependencies completely different.

As a result, because of this undefined behavior, you get breakage;
because you are relying on package manager behavior. Explicitly
specifying it is the way to go; but, why allow SLOT-less dependencies?

There are two ways to resolve this unspecified behavior:

    1) We specify a default, such that package managers co-operate.

    2) We disallow that syntax, because it results in breakage.

Which one depends on what other PMS consumers think about it.

What do you think about this look on it?

> Such a change would introduce policy into PMS which is not
> the right way to go.

There are quite a few policies in the PMS; which I question why they
can be in there, and this policy cannot be.

For example in 5.2.1 we see:

    In profiles, the parent file may not contain comments.

Then we could just as well have something like:

    In ebuilds, *DEPEND may not contain SLOT-less dependencies.

Why is the first one permitted in the PMS and the second one not right?

> If a dependency on a specific SLOT value is needed then it should be
> explicitly specified in the ebuild.

Given that it is otherwise undefined behavior that yields breakage
when shared among different implementations, it seems like this is
always needed. Or are there reasons to allow undefined behavior here?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Rich Freeman]

On Sun, Dec 8, 2013 at 3:01 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
> Our rules of slot/subslot dependencies and slot operators are just
> complicated enough, so I really would dislike complicating them even
> more by having an EAPI dependent default. In addition, from a package
> manager view there is nothing special at all about slot 0, so there's
> no reason to prefer it over other values.

I can see that argument, but what then?  What should be the best
practice for a maintainer?

A new slot of a package (which doesn't exist today) may or may not
work with any ebuild in the system.  Should it be considered a best
practice then to specify || deps with all slots that are known to work
in the tree?  Or should we just trust to luck and consider it
acceptable for maintainers to add new slots of commonly-used libs and
users and downstream maintainers can deal with the resulting breakage?

Library maintainers don't seem to like dealing with that, so they just
stick new slots in an entirely new package, and then we end up with
all the || dependencies anyway and we make no use of the nice slot
syntax because it is prone to breakage.

It seems like the current way we handle slots for dependencies works
just fine until somebody actually tries to introduce a new slot for a
package, and then a whole pile of assumptions comes crashing down.

Rich

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Ulrich Mueller]

>>>>> On Sun, 8 Dec 2013, Tom Wijsman wrote:

> The PMS describes package manager behavior required to support an
> ebuild repository. If I read the PMS correctly, SLOT-less dependencies
> have undefined behavior; this makes it so that if you have a different
> package manager using the same ebuild repository, it could interpret
> the dependencies completely different.

Nothing undefined here. A dependency without a slot means that all
slot values are acceptable. And all package managers interpret it in
the same way.

Ulrich

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Tom Wijsman]

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

On Sun, 8 Dec 2013 21:01:00 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Sun, 8 Dec 2013, Rich Freeman wrote:
> 
> > Sure it does - it defaults to :* when :* was never specified. I
> > don't see how defaulting to :0= is a "policy" any more than :* is.
> 
> Defaulting to :* is just the long term behaviour from EAPIs 0 to 4
> when no slot operator was specified.

Which section in the PMS is this specified?

> This is consistent with what we haved for versioned dependencies.
> When you don't specify a version, then all versions are good.

Good idea.

> Similarly, when you don't specify a slot, then all slots are good.

Not so good idea; because if all slot would be good by default, then
why have slots in the first place? Are we using SLOT right at all?

> Our rules of slot/subslot dependencies and slot operators are just
> complicated enough, so I really would dislike complicating them even
> more by having an EAPI dependent default.

Is it complicated?

1. Dev changes to EAPI 6 on a revision or version bump.
2. Dev tests the ebuild.
2.a. It works; the ebuild defaults to depend on :0=.
2.b. It breaks, dev checks dependency; the ebuild now depends on :2=.
3. Dev commits.

The developer needs to be aware of new PMS versions; thus, given that
news is brought out about this the developer is aware of the change.

> In addition, from a package
> manager view there is nothing special at all about slot 0, so there's
> no reason to prefer it over other values.

In reality, we use it in a special way; it's time to make the resources
that we use reflect that and stop relying on unspecified behavior.

(Or change reality to match our resources; though, doing thousand of
commits compared to changing our resources might not be the way to go.)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Ciaran McCreesh]

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

On Sun, 8 Dec 2013 21:21:59 +0100
Tom Wijsman <TomWij@gentoo.org> wrote:
> On Sun, 8 Dec 2013 21:01:00 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote:
> > >>>>> On Sun, 8 Dec 2013, Rich Freeman wrote:
> > 
> > > Sure it does - it defaults to :* when :* was never specified. I
> > > don't see how defaulting to :0= is a "policy" any more than :* is.
> > 
> > Defaulting to :* is just the long term behaviour from EAPIs 0 to 4
> > when no slot operator was specified.
> 
> Which section in the PMS is this specified?

It's not, exactly. Paludis treats :* and "no slot specified"
differently. The former allows for runtime switching of slots. The
latter assumes "we don't know which slot it needs, so to be safe we'll
have to assume it could be any of them".

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Ciaran McCreesh]

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

On Sun, 8 Dec 2013 21:21:52 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> > The PMS describes package manager behavior required to support an
> > ebuild repository. If I read the PMS correctly, SLOT-less
> > dependencies have undefined behavior; this makes it so that if you
> > have a different package manager using the same ebuild repository,
> > it could interpret the dependencies completely different.
> 
> Nothing undefined here. A dependency without a slot means that all
> slot values are acceptable. And all package managers interpret it in
> the same way.

Actually, Paludis interprets a lack of slot dependency as a "don't
know", and assumes that it might be unsafe to switch slots at runtime
in these cases.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Tom Wijsman]

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

On Sun, 8 Dec 2013 21:21:52 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> Nothing undefined here. A dependency without a slot means that all
> slot values are acceptable.

Is that stated in the PMS?

> And all package managers interpret it in the same way.

Because it is the previous behavior (adopted from versions?); it is
undefined behavior from the PMS point of view if it is not stated.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Tom Wijsman]

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

On Sun, 8 Dec 2013 21:21:52 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> And all package managers interpret it in the same way.

If all package managers do as such, that allows PMS to easily cover it.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Ulrich Mueller]

>>>>> On Sun, 8 Dec 2013, Ciaran McCreesh wrote:

>> Nothing undefined here. A dependency without a slot means that all
>> slot values are acceptable. And all package managers interpret it in
>> the same way.

> Actually, Paludis interprets a lack of slot dependency as a "don't
> know", and assumes that it might be unsafe to switch slots at runtime
> in these cases.

I stand corrected. However, that concerns only updates, but not the
way the dependency is resolved when it is met for the first time.

Ulrich

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Michał Górny]

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

Dnia 2013-12-08, o godz. 20:26:44
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> napisał(a):

> On Sun, 8 Dec 2013 21:21:52 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote:
> > > The PMS describes package manager behavior required to support an
> > > ebuild repository. If I read the PMS correctly, SLOT-less
> > > dependencies have undefined behavior; this makes it so that if you
> > > have a different package manager using the same ebuild repository,
> > > it could interpret the dependencies completely different.
> > 
> > Nothing undefined here. A dependency without a slot means that all
> > slot values are acceptable. And all package managers interpret it in
> > the same way.
> 
> Actually, Paludis interprets a lack of slot dependency as a "don't
> know", and assumes that it might be unsafe to switch slots at runtime
> in these cases.

So we should basically encourage people to explicitly state ':*' when
they mean that, correct? Because I can tell you that right now many
people don't use that because they see it as redundant.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Ciaran McCreesh]

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

On Sun, 8 Dec 2013 22:54:39 +0100
Michał Górny <mgorny@gentoo.org> wrote:
> > Actually, Paludis interprets a lack of slot dependency as a "don't
> > know", and assumes that it might be unsafe to switch slots at
> > runtime in these cases.
> 
> So we should basically encourage people to explicitly state ':*' when
> they mean that, correct? Because I can tell you that right now many
> people don't use that because they see it as redundant.

That was the point of adding :*, yes. Repoman was supposed to be
updated to catch DEPEND+RDEPEND deps which could match multiple slots
and which didn't specify either := or :*. AFAIK this never actually
happened.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Patrick Lauer]

On 12/09/2013 12:54 AM, Tom Wijsman wrote:

> Creating a new SLOT is the most sane thing going forward; but, as the
> default (:*) depends on any SLOT, this needs a half thousand commits to
> fix up reverse dependencies. Thus, instead a new package is made. [1]


Pff. Lazy.



> When our defaults force us down such path, that can't be good and it
> affects the quality of our Portage tree; so, this makes me wonder, can
> we change the default from :* to :0? What do you think?

That just shifts the breakage to other people, who then have to do more
work.

> If we agree we do this; in order to change :* to :0, we need to change
> the PMS to cover this change and implement it in the package managers.
> 
> Before we do that, we need to evaluate how practical this is to apply.
> While we are trying to fix the default behavior, what would changing
> the default from :* to :0 break?
> 
> One thing that directly comes to mind is that dependencies that have no
> SLOT="0" ebuild present would need us to manually specify a specific
> SLOT; given that this is a not so common situation, the amount of
> commits needed here is low.

And now you make updating a lot more fun, because slotted packages need
to be explicitly changed if there's a new slot happening. Just to hide
your own laziness.

> Another thing that comes to mind is that we need to check what to do
> with packages were the highest available version does not belong to
> SLOT="0"; technically, restricting these to SLOT="0" will not cause
> breakage, it might however cause some blockers. We'll have to look
> closer into how we can alleviate this result.

Yup, bad idea.

500 commits vs. making things more complicated for everyone ... srsly?

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Tom Wijsman]

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

On Mon, 09 Dec 2013 07:57:34 +0800
Patrick Lauer <patrick@gentoo.org> wrote:

> On 12/09/2013 12:54 AM, Tom Wijsman wrote:
> 
> > Creating a new SLOT is the most sane thing going forward; but, as
> > the default (:*) depends on any SLOT, this needs a half thousand
> > commits to fix up reverse dependencies. Thus, instead a new package
> > is made. [1]
> 
> Pff. Lazy.

Yes, but who is lazy here? The person that wants to commit the
dependency or the people whom depend on the implicit :* behavior?

Or someone else?

> > When our defaults force us down such path, that can't be good and it
> > affects the quality of our Portage tree; so, this makes me wonder,
> > can we change the default from :* to :0? What do you think?
> 
> That just shifts the breakage to other people, who then have to do
> more work.

Doing a smaller bit of useful work to spare out tons of useless work.

As part of a new EAPI it doesn't break. Why do you think so?

Why would this yields more work? The dependencies need to be checked
anyway as port of version bumps; so, better do them right at once.

> > If we agree we do this; in order to change :* to :0, we need to
> > change the PMS to cover this change and implement it in the package
> > managers.
> > 
> > Before we do that, we need to evaluate how practical this is to
> > apply. While we are trying to fix the default behavior, what would
> > changing the default from :* to :0 break?
> > 
> > One thing that directly comes to mind is that dependencies that
> > have no SLOT="0" ebuild present would need us to manually specify a
> > specific SLOT; given that this is a not so common situation, the
> > amount of commits needed here is low.
> 
> And now you make updating a lot more fun, because slotted packages
> need to be explicitly changed if there's a new slot happening. Just
> to hide your own laziness.

As per my first question of this reply, whose laziness do you mean?

> > Another thing that comes to mind is that we need to check what to do
> > with packages were the highest available version does not belong to
> > SLOT="0"; technically, restricting these to SLOT="0" will not cause
> > breakage, it might however cause some blockers. We'll have to look
> > closer into how we can alleviate this result.
> 
> Yup, bad idea.

As part of a new EAPI the above is no longer necessary as the change
isn't done in place; furthermore, even if we don't do it as part
of a new EAPI repoman can cover this with a QA warning.

> 500 commits vs. making things more complicated for everyone ... srsly?

Why do you think this idea makes things more complicated for everyone?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Rich Freeman]

On Sun, Dec 8, 2013 at 6:57 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 12/09/2013 12:54 AM, Tom Wijsman wrote:
>>
>> One thing that directly comes to mind is that dependencies that have no
>> SLOT="0" ebuild present would need us to manually specify a specific
>> SLOT; given that this is a not so common situation, the amount of
>> commits needed here is low.
>
> And now you make updating a lot more fun, because slotted packages need
> to be explicitly changed if there's a new slot happening. Just to hide
> your own laziness.

Frankly, your tone is rude here.  Don't personalize things.  The goal
is to eliminate non-value-added work.  If a change makes work for
others that should be pointed out.  If a change saves somebody time,
that isn't "laziness."  Work isn't a virtue - accomplishing something
is.  Discuss the merits of the proposal, and don't debate the morals
of the person making the proposal.

Second, I'm not sure exactly what you're trying to say here.  Slotted
packages don't need to be changed under the proposed approach any more
than they otherwise would.  If you have SLOT=0 of libfoo and want to
introduce SLOT=1 it is the same amount of work for the libfoo
maintainer either way.  The only difference is that if half the tree
depends on libfoo and breaks with libfoo:1 then there are a bazillion
failures all the sudden.

If you meant that packages that depend on slotted packages need to be
changed, then that isn't really correct either.  If a package depends
on libfoo:0 instead of libfoo:*, it will work just fine when libfoo:1
is introduced - it will just continue to pull in libfoo:0.  Then over
time maintainers can test and add an || dep for libfoo:1 and the
package will work with either.

The status quo requires the libfoo maintainers to do a ton of work to
get everybody to change their deps before introducing a new slot.
Either that or they do what everybody else apparently does and not use
slots at all, just creating libfoo2.  Well, if you can't reliably
create new slots for dependencies, then what is the point of having a
syntax for slot dependencies in the first place?

On IRC there was some discussion and it may make sense to not make the
default :0 (or :0=), but rather to just not have any default in a
future EAPI - every single dependency line would therefore contain a
slot.  I'm not convinced wildcards should even be allowed - the whole
point of introducing new slots is that the new version may not be
compatible, so how can you say in advance that any slot is acceptable?
 If the new library is API-compatible then it should just be a new
subslot in the same slot, and if it is ABI-compatible then it should
be in the same subslot.  The whole point of subslots is to handle
packages that have API breaks, and I don't see how wildcards against
future versions not even written yet can be appropriate there.  The
only thing that it does is saves maintainers the trouble of looking up
what slots the package was actually tested against, which sounds a bit
like a certain word that starts with l...  :)

Rich

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[heroxbd]

Rich Freeman <rich0@gentoo.org> writes:

> A new slot of a package (which doesn't exist today) may or may not
> work with any ebuild in the system.  Should it be considered a best
> practice then to specify || deps with all slots that are known to work
> in the tree?  Or should we just trust to luck and consider it
> acceptable for maintainers to add new slots of commonly-used libs and
> users and downstream maintainers can deal with the resulting breakage?
>
> Library maintainers don't seem to like dealing with that, so they just
> stick new slots in an entirely new package, and then we end up with
> all the || dependencies anyway and we make no use of the nice slot
> syntax because it is prone to breakage.
>
> It seems like the current way we handle slots for dependencies works
> just fine until somebody actually tries to introduce a new slot for a
> package, and then a whole pile of assumptions comes crashing down.

How about defining a QA workflow for introducing a new slot of a
library, such as "mask it and open a tracker bug until every individual
reverse dependencies are checked"?

Benda

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Rich Freeman]

On Sun, Dec 8, 2013 at 9:37 PM,  <heroxbd@gentoo.org> wrote:
>
> How about defining a QA workflow for introducing a new slot of a
> library, such as "mask it and open a tracker bug until every individual
> reverse dependencies are checked"?
>

The problem with this is that it puts the onus on the person who wants
to make forward progress (adding support for a new library version).
That means that they have incentive to either not bother with the new
library version (causing Gentoo to stagnate), or use hacks like giving
the library a new name (which we have examples in the tree of).

Now, perhaps a more balanced approach might be to mask it and give 15
days notice on -dev, and then it can be unmasked.  Anybody who cares
about the library can test the new version, and if necessary update
their dependencies to use the previous slot only (and if 15 days isn't
enough time they can just update the dep right away and then update it
again after they get around to testing it).  Those who don't want to
have to deal with that can just define their slot dependencies
explicitly so that this policy will never apply to them.

In order for a QA policy to be effective it has to either be minimally
intrusive, or make the cost of compliance lower than the cost of
workarounds or benign neglect.  People don't HAVE to maintain
packages, after all...

Rich

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[heroxbd]

[reordered to ease replying]

Rich Freeman <rich0@gentoo.org> writes:
> Now, perhaps a more balanced approach might be to mask it and give 15
> days notice on -dev, and then it can be unmasked.  Anybody who cares
> about the library can test the new version, and if necessary update
> their dependencies to use the previous slot only (and if 15 days isn't
> enough time they can just update the dep right away and then update it
> again after they get around to testing it).  Those who don't want to
> have to deal with that can just define their slot dependencies
> explicitly so that this policy will never apply to them.

Good idea!

> The problem with this is that it puts the onus on the person who wants
> to make forward progress (adding support for a new library version).
> That means that they have incentive to either not bother with the new
> library version (causing Gentoo to stagnate), or use hacks like giving
> the library a new name (which we have examples in the tree of).

> In order for a QA policy to be effective it has to either be minimally
> intrusive, or make the cost of compliance lower than the cost of
> workarounds or benign neglect.  People don't HAVE to maintain
> packages, after all...

I agree with that. We are all aware that every gcc slot bump costs so
much work (and frustration).

At the same time, it worth the hard work for a well-organized tree and
flexibility.

The only draw back is lack of man power to do it right like bug
493652. Yes, when a library introduces a new not fully compatible
version, it naturally implies a lots of work to do for downstream like
us. There is no escape: If we hack a versioned library name, it will
bite us in the future. The question becomes: Who should do this heavy
lifting?

This is a glitch in the amount of work needed when a single-slotted
library suddenly becomes slotted. IMHO, let's form a slotting group in
the reformed QA team who will donate manpower for such situation to aid
the library maintainer. Anyone who wants to make forward progress but
does not have enough time seeks help to the slotting group.

What do you say?

Benda

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Sergey Popov]

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

08.12.2013 20:54, Tom Wijsman пишет:
> Hello fellow developers
> 
> == Situation ==
> 
> When specifying a dependency like cat/pkg it will default to cat/pkg:*
> which is defined in `man 5 ebuild` as:
> 
>     * 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.
> 
> This default reflects different behavior than what we use slots for,
> besides allowing side-by-side installations we rather use it to
> specifically depend on a new major version. (eg. dev-libs/glib).
> 
> Let's say I want to a add a new major version of cat/pkg to the Portage
> tree, introducing it in the same SLOT="0" isn't an option. This gives
> us two options, one is SLOT="2", the other is to create cat/pkg2 or so.
> 
> Creating a new SLOT is the most sane thing going forward; but, as the
> default (:*) depends on any SLOT, this needs a half thousand commits to
> fix up reverse dependencies. Thus, instead a new package is made. [1]
> 
> When our defaults force us down such path, that can't be good and it
> affects the quality of our Portage tree; so, this makes me wonder, can
> we change the default from :* to :0? What do you think?
> 
>  [1] https://bugs.gentoo.org/show_bug.cgi?id=493652
>      "media-libs/libsdl2: should be a SLOT=2 of media-libs/libsdl"
> 
> == Task ==
> 
> If we agree we do this; in order to change :* to :0, we need to change
> the PMS to cover this change and implement it in the package managers.
> 
> Before we do that, we need to evaluate how practical this is to apply.
> While we are trying to fix the default behavior, what would changing
> the default from :* to :0 break?
> 
> One thing that directly comes to mind is that dependencies that have no
> SLOT="0" ebuild present would need us to manually specify a specific
> SLOT; given that this is a not so common situation, the amount of
> commits needed here is low.
> 
> Another thing that comes to mind is that we need to check what to do
> with packages were the highest available version does not belong to
> SLOT="0"; technically, restricting these to SLOT="0" will not cause
> breakage, it might however cause some blockers. We'll have to look
> closer into how we can alleviate this result.
> 
> Is there anything else we need to take into account?
> 
> == Summary ==
> 
> Situation:
> 
>     Defaulting to :* on SLOT-less dependencies makes it hard to add a
>     new SLOT to a package, using :0 instead would not make this a
>     problem and not require to fix up all reverse dependencies.
> 
> Task:
> 
>     Check results, correct some exceptions, update PMS, implement it.
> 
> Thank you in advance for participating in this discussion.
> 

In short - please do NOT do this. More complicated answer - you break
the whole idea of slots. When user types 'emerge cat/foo' it means now -
"i want cat/foo, whatever versions it will be(depending on mask,
keywords, etc, etc)". Your proposal changes this behaviour drastically,
and reasons for such changes are not worth it.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Tom Wijsman]

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

On Mon, 09 Dec 2013 10:52:15 +0400
Sergey Popov <pinkbyte@gentoo.org> wrote:

> In short - please do NOT do this.

Why not? What about other solutions? What do you think?

There have come up several solutions, the one suggested in the first
mail is no longer of interest due to SLOT="0" no longer being special;
now ideas tend to focus towards disallowing slot-less dependencies, or
otherwise implement under the form of a repoman warning.

> More complicated answer - you break
> the whole idea of slots. When user types 'emerge cat/foo' it means
> now - "i want cat/foo, whatever versions it will be(depending on mask,
> keywords, etc, etc)". Your proposal changes this behaviour
> drastically, and reasons for such changes are not worth it.

A package ATOM used in another place warrants another discussion; when
an user types it, what does the user mean? We could opt to not change
the behavior for users if their usage is different.

Note that the syntax (and thus usage) is different by design:

     $ emerge -1pv '|| ( sys-apps/openrc sys-apps/systemd )'
    !!! '|| ( sys-apps/openrc sys-apps/systemd )' is not a valid
        package atom.
    !!! Please check ebuild(5) for full details.

The reasons for changing dependency syntax are worth it:

For the dependency syntax, having :* as a default breaks things or
causes a lot of work. If explicit slots (or :0) were the default, it
works and you spare out dealing with lots of reverse dependencies when
you introduce a new slot.

When you depend on libfoo; I think you mean to depend on the libfoo
that is currently in the Portage tree (eg. libfoo:0 or so), whereas
libfoo:* would break as soon as the libfoo maintainer starts a new slot.

With libfoo:*, this then results in the following procedure:

1. Add libfoo:2 to the Portage tree and package.mask.
2. Inform everyone to update the dependency accordingly, wait for it.
3. Unmask libfoo:2. (Somewhere in the future)

Whereas with an implicit or explicit libfoo:${SLOT}, this results in:

1. Add libfoo:2 to the Portage tree. (Right now, without mask)
2. Maintainers support libfoo:2 over time as they bump packages.

As the former is frustrating, it can have library maintainers create a
new package instead of a new SLOT or not add the new version at all;
whereas the latter would allow the library maintainer to just add it,
especially as it is the task of individual maintainers to test their
package against new libraries as they come along.

Thus, that's why I'd like to see slot-less dependencies go and make it
policy or at least a repoman QA warning that people specify them.

Specifying it without a slot is moving the work of dependency testing
on the library maintainer instead of the package maintainer, causing the
library maintainer to either test tons of packages or file tons of bug.

Why have the library maintainer do extra work when a package maintainer
can just test it instead during a version bump? (As required anyway)

What do you think? Why do you think we should still keep a default :*?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Rich Freeman]

On Mon, Dec 9, 2013 at 5:55 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> For the dependency syntax, having :* as a default breaks things or
> causes a lot of work. If explicit slots (or :0) were the default, it
> works and you spare out dealing with lots of reverse dependencies when
> you introduce a new slot.

I was giving this some more thought and here is another way of looking at this.

Let A be the set of all situations where it makes sense to create a
new slot for a package that has reverse dependencies.

Let B be the subset of A where it makes sense for those reverse
dependencies to automatically use the new slot without any
intervention by the reverse dep maintainers.

If |B| >> |A \ B| then the current default makes sense.  (That is, if
the number of elements in B is much larger than the number of elements
in A that aren't in B.)

If |B| << |A \ B| then it would make sense to require all slot
dependencies to be explicit, and the ":*" dependency to be frowned
upon in general.

I think that the above just makes sense if you think about it, so I'll
use that as my initial premise for what follows.  By all means
challenge this.

So, what I'm going to do now is speculate that B = ∅ (that is B is the
empty set).  Therefore, it makes sense to get rid of the current
default and require all slot deps to be explicit.

If you think that B isn't the empty set, it is trivial for you to
demonstrate that this is the case.  Simply give me a single example of
a situation where:
1.  It makes sense for a dep to use a new slot.
2.  It makes sense for all of its reverse deps to automatically use
the new slot without any further intervention by the individual
reverse dep maintainers.

I can't think of any, and I'm all ears if somebody else can.  It seems
to me that our current default optimizes for a situation that is
dubious from a QA standpoint.  Its main virtue is that you don't have
to go look up what the current slot is for slot-less packages, but
honestly if you just stuck a :0 on every line of your ebuild chances
are it would work on the first install and at least the behavior would
be consistent for anybody else who uses it.

Rich

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Ulrich Mueller]

>>>>> On Mon, 9 Dec 2013, Rich Freeman wrote:

> If you think that B isn't the empty set, it is trivial for you to
> demonstrate that this is the case.  Simply give me a single example of
> a situation where:
> 1.  It makes sense for a dep to use a new slot.
> 2.  It makes sense for all of its reverse deps to automatically use
> the new slot without any further intervention by the individual
> reverse dep maintainers.

app-editors/emacs, to start with.

If you go through the list of about 400 packages that have more than
one slot (out of 17000 packages in the portage tree), I'm sure you'll
find many more that fall in B. On first glance, only a minor part of
these 400 seem to be libraries.

Ulrich

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Tom Wijsman]

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

On Mon, 9 Dec 2013 17:19:34 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Mon, 9 Dec 2013, Rich Freeman wrote:
> 
> > If you think that B isn't the empty set, it is trivial for you to
> > demonstrate that this is the case.  Simply give me a single example
> > of a situation where:
> > 1.  It makes sense for a dep to use a new slot.
> > 2.  It makes sense for all of its reverse deps to automatically use
> > the new slot without any further intervention by the individual
> > reverse dep maintainers.
> 
> app-editors/emacs, to start with.
> 
> If you go through the list of about 400 packages that have more than
> one slot (out of 17000 packages in the portage tree), I'm sure you'll
> find many more that fall in B. On first glance, only a minor part of
> these 400 seem to be libraries.

It is surprising that there are only ~400 packages that have multiple
slots available in the Portage tree; trying to reproduce this, I get a
similar number. Out of a ~350 total, ~75 contain "libs/", ~100 contain
"dev-java/" (almost a third); there's are some ruby and haskell libs
too. These groups are almost all libraries, so it somewhat fifty-fifty. 

Note how Java packages already have a project policy to explicitly
specify slots on dependencies; as the eclass functionality relies on
that. As a consequence, it is easy to add a new slot to them. For the
Java herd it makes total sense to use explicit slots that way.

With new version bumps to reverse dependencies of dev-java libraries;
it is interesting to note that as time goes by, you will eventually
need to depend on the newer slot instead as upstream upgrades its
support for that dev-java library; dropping support for the old version.

But that's just a third and not necessarily representable, it can
however show how it works in practice.

Libraries' slot usage is harder to tell and needs a more thorough look
as to how these are done. It's easier to tell by someone whom has more
experience with how these libraries are versioned, seeing that most of
these are media-libs and x11-libs I'll try asking the relevant herds.

For applications (or should we say "all the rest") I think we need to
look at which kind of packages these are and what the slots mean.

For example, there are ~14 kernel sources that have multiple slots,
which are as far as I know not used as dependencies; it just serves
quite handy for the user to add it to the world file. There is also
www-client/google-chrome and sys-boot/grub, those are packages where
slots are meant for the user and not for reverse dependencies.

What do you think? Does someone have a different view? Please share. :)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/12/13 03:21 PM, Tom Wijsman wrote:
> On Sun, 8 Dec 2013 21:01:00 +0100 Ulrich Mueller <ulm@gentoo.org>
> wrote:
> 
>>>>>>> On Sun, 8 Dec 2013, Rich Freeman wrote:
>> 
>>> Sure it does - it defaults to :* when :* was never specified.
>>> I don't see how defaulting to :0= is a "policy" any more than
>>> :* is.
>> 
>> Defaulting to :* is just the long term behaviour from EAPIs 0 to
>> 4 when no slot operator was specified.
> 
> Which section in the PMS is this specified?
> 
>> This is consistent with what we haved for versioned
>> dependencies. When you don't specify a version, then all versions
>> are good.
> 
> Good idea.
> 
>> Similarly, when you don't specify a slot, then all slots are
>> good.
> 
> Not so good idea; because if all slot would be good by default,
> then why have slots in the first place? Are we using SLOT right at
> all?
> 

SLOT allows multiple versions of a package to be installed
concurrently.  In the case of libraries or dependencies, this supports
the specific case where certain ebuilds only support a particular
SLOT.  However, that doesn't mean that all packages need to be tied to
one slot or another.

It should be noted here that this discussion is revolving entirely
around multi-SLOT libraries.  Firstly, there are packages like
dev-db/postgresql that use SLOTs not just for library provision.
Secondly, SLOT= on the libraries being discussed may not actually be
the correct method to deal with this at all, and rather, these libs
should be using a subslot and the rdeps be using an upper-bound
version on dependency atoms to limit which dependency it can be used
with--it all depends on whether the library maintainer intends to
support both major versions in the long term or not.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlKngmsACgkQ2ugaI38ACPCfxwD/YifeWm+rrAN1om9HP41ATO6Z
pqKChxQaayjzfWtKyeMA/2K9AJFvhowBSKHBatAilfWGuI2L25dMHFidOxzLpZX3
=KW2i
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Tom Wijsman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 10 Dec 2013 16:06:51 -0500
Ian Stakenvicius <axs@gentoo.org> wrote:

> SLOT allows multiple versions of a package to be installed
> concurrently. In the case of libraries or dependencies, this supports
> the specific case where certain ebuilds only support a particular
> SLOT.  However, that doesn't mean that all packages need to be tied to
> one slot or another.

This discussion results in no change for the above paragraph; it will
still allow multiple versions to be installed, packages can still be
tied to multiple slots by specifying :*.

We're kind of discussion a problem here we don't know the answer to;
because in order to obtain numbers, we have to enumerate everything to
see how slots are being used. And only then we can determine that X%
would depend on a specific :${SLOT} and that (100-X)% would depend
on :*; the comparison here is what would suggest the default.

In another part in this thread we went looking for packages that
have multiple slots to judge; but, it comes to mind now that we might
want to look at the opposite which might be easier to study:

"What if we create multiple slots for libraries that have none?"

In order to do so, it again depends on how slots are being used:

"Why is a new slot made?"

One argument is "side-by-side install", another argument is "API
breakage" (eg. dev-java); some might only pick one argument or the
other, though what jumps to mind is that having the need for a
side-by-side install is the consequence of API breakage. Leading to:

"Do we create a new package or a new slot?"

It looks cleaner to me to have slots; because if you look at what a
"package" means, API breakages or major versions do not necessarily
mean it is a new package (depending on the way you look at it). 

> It should be noted here that this discussion is revolving entirely
> around multi-SLOT libraries.

Anything that fits a dependency relationship, thus almost entirely; as
shown in the other thread with those numbers there are some applications
that are also used as a dependency, that don't have to be a library.

> Firstly, there are packages like
> dev-db/postgresql that use SLOTs not just for library provision.

True, but I think we should look at the Portage tree at a wider scale
than bring up single examples; I think we have an example for multiple
variations, but how do we reflect the majority in the Portage tree?

> Secondly, SLOT= on the libraries being discussed may not actually be
> the correct method to deal with this at all, and rather, these libs
> should be using a subslot and the rdeps be using an upper-bound
> version on dependency atoms to limit which dependency it can be used
> with--it all depends on whether the library maintainer intends to
> support both major versions in the long term or not.

There are some varying thoughts wrt SLOT= here and there; looking at
what the devmanual says [1], it mentions: "Packages can support having
multiple versions installed simultaneously. This is useful for
libraries which may have changed interfaces between versions."

It almost seems as if it the combination of those both is the only
reason for the usage of SLOT= in the context of dependencies and/or
libraries. In this context, are there others one can think of?

That same page of the devmanual covers sub slots, it says [1]:
"Sometimes a package installs a library that changes interfaces between
versions, but it's undesirable or inconvenient to allow some of these
versions to be installed simultaneously. "

What is written here is different than our context; because we're
trying to have multiple slots here, and sub slots do the opposite.

 [1]: http://devmanual.gentoo.org/general-concepts/slotting

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJSp6UoAAoJEJWyH81tNOV9i70H/jjM+EHLIn8uRwdO/G1XU226
gWpow/6D8mB5nwbbZJR3Zu6fH8JX7+sJbPuYlvJYzy2IYX67UH2PHsgbnFqxjhpa
/6EDi/MTtbL/0RdqbY15WkqOljl2+74vnwzctMnJSOQMCgKXVpFOiOT+XQxuPvGd
aFKlUE6wZZVQRrqb+Eb8VAvQx7ob+3ez9EUzzAY213uicIXL/n2h6GGS4+Bj1h5Z
7MOs4whuvQXbC94jdLCsoiMozau3ChpxZFhovFLfXGo1Nqg2rruxtld7KVsN+pIr
0mr+4mNnmMooZ1KUKP26RsY8kDvtoEI1GQZ81CmCh1acKMpvDUwjpv8mORb0sBU=
=5EzT
-----END PGP SIGNATURE-----