| 1 |
Mike Frysinger schrieb: |
| 2 |
> On Sunday, October 02, 2011 08:58:19 Chí-Thanh Christopher Nguyễn wrote: |
| 3 |
>> Samuli Suominen schrieb: |
| 4 |
>>>> Please point to existing authoritative documentation which says that |
| 5 |
>>>> downgrades are unacceptable. |
| 6 |
>>>> |
| 7 |
>>>>> It is NOT gentoo-x86 compatible package in it's current form. |
| 8 |
>>>> |
| 9 |
>>>> It sets correct dependency on an existing ebuild in tree. The dependency |
| 10 |
>>>> is only build time, users can upgrade linux-headers again afterwards. |
| 11 |
>>>> The application itself is v4l2 compatible. |
| 12 |
>>> |
| 13 |
>>> common sense... |
| 14 |
>>> |
| 15 |
>>> http://bugs.gentoo.org/show_bug.cgi?id=311241#c2 |
| 16 |
>>> http://bugs.gentoo.org/show_bug.cgi?id=311241#c5 |
| 17 |
>> |
| 18 |
>> linux-headers is not a library, it is strictly a build time dependency |
| 19 |
>> for all packages which I am aware of. |
| 20 |
> |
| 21 |
> forcing downgrades of random packages is extremely poor behavior. it doesn't |
| 22 |
> matter if it's DEPEND or RDEPEND behavior. if your one package is the last |
| 23 |
> thing to get installed, then you leave the system in a poor state. |
| 24 |
|
| 25 |
I agree that a downgrade is a bit inconvenient for users. But if another |
| 26 |
package is built later with DEPEND on newer linux-headers or emerge |
| 27 |
--deep option, then it will get upgraded again. As no package runtime |
| 28 |
depends on it, the system will not function any worse with old |
| 29 |
linux-headers. |
| 30 |
|
| 31 |
I propose that if linux-headers maintainers want to make downgrades |
| 32 |
"illegal" (as the new summary to bug 361181 suggests) or restricted in |
| 33 |
some way, they do so in policy or code. Not by surprise treecleaning of |
| 34 |
packages. |
| 35 |
|
| 36 |
> further, when the newer version gets stabilized and then the older ones |
| 37 |
> dropped, what then ? your package is broken. |
| 38 |
|
| 39 |
Yes, when the older one is dropped _that_ would be reason for |
| 40 |
masking+removal. However I have not seen any plans of doing so. Actually |
| 41 |
the current amd64 stable 2.6 versions are 35, 26 and 10 months old |
| 42 |
respectively, I wouldn't expect that to happen any time soon. |
| 43 |
|
| 44 |
> skipping 30 days is a bit premature, but re-adding it at this point doesn't |
| 45 |
> make sense. fix it and re-add it, or don't re-add it at all. |
| 46 |
|
| 47 |
That seems to be the only sensible solution at this point. I will |
| 48 |
probably find time next week or so to create and test a new ebuild. |
| 49 |
|
| 50 |
Though I must say that allowing this clear policy violation to stand |
| 51 |
while I don't see any policy violation in my ebuild leaves a bad impression. |
| 52 |
|
| 53 |
|
| 54 |
Best regards, |
| 55 |
Chí-Thanh Christopher Nguyễn |
Archives