On Sun, 8 Dec 2013 20:14:47 +0100 Ulrich Mueller <u...@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 : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
