| 1 |
On Sun, 8 Dec 2013 20:14:47 +0100 |
| 2 |
Ulrich Mueller <ulm@g.o> wrote: |
| 3 |
|
| 4 |
> >>>>> On Sun, 8 Dec 2013, Andreas K Huettel wrote: |
| 5 |
> |
| 6 |
> > How about changing this in the next EAPI instead? |
| 7 |
> |
| 8 |
> > E.g., in EAPI=6, if no slot dependency is given in a dependency |
| 9 |
> > specification, default to :0 |
| 10 |
> |
| 11 |
> PMS just provides a mechanism, but doesn't prefer one SLOT value over |
| 12 |
> another. |
| 13 |
|
| 14 |
The PMS describes package manager behavior required to support an |
| 15 |
ebuild repository. If I read the PMS correctly, SLOT-less dependencies |
| 16 |
have undefined behavior; this makes it so that if you have a different |
| 17 |
package manager using the same ebuild repository, it could interpret |
| 18 |
the dependencies completely different. |
| 19 |
|
| 20 |
As a result, because of this undefined behavior, you get breakage; |
| 21 |
because you are relying on package manager behavior. Explicitly |
| 22 |
specifying it is the way to go; but, why allow SLOT-less dependencies? |
| 23 |
|
| 24 |
There are two ways to resolve this unspecified behavior: |
| 25 |
|
| 26 |
1) We specify a default, such that package managers co-operate. |
| 27 |
|
| 28 |
2) We disallow that syntax, because it results in breakage. |
| 29 |
|
| 30 |
Which one depends on what other PMS consumers think about it. |
| 31 |
|
| 32 |
What do you think about this look on it? |
| 33 |
|
| 34 |
> Such a change would introduce policy into PMS which is not |
| 35 |
> the right way to go. |
| 36 |
|
| 37 |
There are quite a few policies in the PMS; which I question why they |
| 38 |
can be in there, and this policy cannot be. |
| 39 |
|
| 40 |
For example in 5.2.1 we see: |
| 41 |
|
| 42 |
In profiles, the parent file may not contain comments. |
| 43 |
|
| 44 |
Then we could just as well have something like: |
| 45 |
|
| 46 |
In ebuilds, *DEPEND may not contain SLOT-less dependencies. |
| 47 |
|
| 48 |
Why is the first one permitted in the PMS and the second one not right? |
| 49 |
|
| 50 |
> If a dependency on a specific SLOT value is needed then it should be |
| 51 |
> explicitly specified in the ebuild. |
| 52 |
|
| 53 |
Given that it is otherwise undefined behavior that yields breakage |
| 54 |
when shared among different implementations, it seems like this is |
| 55 |
always needed. Or are there reasons to allow undefined behavior here? |
| 56 |
|
| 57 |
-- |
| 58 |
With kind regards, |
| 59 |
|
| 60 |
Tom Wijsman (TomWij) |
| 61 |
Gentoo Developer |
| 62 |
|
| 63 |
E-mail address : TomWij@g.o |
| 64 |
GPG Public Key : 6D34E57D |
| 65 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |
Archives