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 |