| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Dear all, |
| 5 |
|
| 6 |
I wish to ask that the council makes a statement regarding the policy |
| 7 |
on "<" versioned dependencies. |
| 8 |
|
| 9 |
Some time ago one of the ebuilds that I maintain was removed twice |
| 10 |
without my consent, the reason given that it violates an alleged |
| 11 |
policy which forbids <sys-kernel/linux-headers-2.6.38 dependency[1]. |
| 12 |
After some discussion, the issue was resolved by fixing the build with |
| 13 |
newer linux-headers. About the policy itself, no consensus was reached. |
| 14 |
|
| 15 |
The issue came up again later[2] and also recently with some x11 |
| 16 |
maintained packages[3]. Today in the boost discussion thread on -dev |
| 17 |
it was brought up too. |
| 18 |
|
| 19 |
If I understand correctly, the proponents of this policy call for some |
| 20 |
kind of reverse visibility requirements, where stabilizing or |
| 21 |
unmasking a package requires all reverse dependencies on that slot to |
| 22 |
work with the newly stabilized/unmasked version. |
| 23 |
|
| 24 |
I dispute that such a policy exists, and am not aware of any |
| 25 |
authoritative document that says so. When asking for documents that |
| 26 |
describe this policy, I was only pointed to common sense. |
| 27 |
|
| 28 |
The reason why I think that < dependencies are not bad is that |
| 29 |
existing users of such packages will typically simply miss out on |
| 30 |
upgrades. Worst case is that trying to newly install a package can |
| 31 |
lead to downgrades or slot conflicts. But the user can see this before |
| 32 |
the build starts, and still decide to abort or uninstall one of the |
| 33 |
problem packages. |
| 34 |
|
| 35 |
The reason why I think that forbidding < dependencies is bad is that |
| 36 |
in the case of x11 maintained packages, their development speed is |
| 37 |
non-uniform. Especially new xorg-server releases can have certain |
| 38 |
x11-drivers packages depend on old versions for weeks or even months. |
| 39 |
Masking xorg-server will hinder X.org progress for everyone else, and |
| 40 |
removing the drivers that continue to work fine with old xorg-server |
| 41 |
would be a disservice to users. |
| 42 |
|
| 43 |
I therefore ask the council to: |
| 44 |
1. State whether such a policy exists |
| 45 |
2. If it exists, repeal this policy |
| 46 |
3. If the policy exists and is not repealed, state what is done with |
| 47 |
packages in violation of that policy (e.g. must they be treecleaned, |
| 48 |
or is it sufficient to p.mask them or drop to ~arch?) |
| 49 |
|
| 50 |
|
| 51 |
Best regards, |
| 52 |
Chí-Thanh Christopher Nguyễn |
| 53 |
|
| 54 |
|
| 55 |
[1] https://bugs.gentoo.org/show_bug.cgi?id=361181 |
| 56 |
[2] https://bugs.gentoo.org/show_bug.cgi?id=414997 |
| 57 |
[3] https://bugs.gentoo.org/show_bug.cgi?id=439714 |
| 58 |
-----BEGIN PGP SIGNATURE----- |
| 59 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 60 |
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ |
| 61 |
|
| 62 |
iEYEARECAAYFAlCQT2YACgkQ+gvH2voEPRB7OACePIMpS1g/G3vQ/yUp2/ngSMVB |
| 63 |
1W0AnRANyPZoANZ8mW4ErjcrwS/+wSuH |
| 64 |
=mzoU |
| 65 |
-----END PGP SIGNATURE----- |
Archives