1 |
On 10/02/2011 11:40 PM, Chí-Thanh Christopher Nguyễn wrote: |
2 |
> Mike Frysinger schrieb: |
3 |
>> the system is functioning wrongly because you're forcing users to needlessly |
4 |
>> upgrade/downgrade packages. in addition, packages in the tree aren't the only |
5 |
>> things to be considered. if the user is building code that works fine against |
6 |
>> the latest stable, but your package forced it to downgrade, they might no |
7 |
>> longer build correctly. |
8 |
> |
9 |
> Then the code is broken that is built outside portage and does not |
10 |
> function correctly with old linux-headers without doing any kind of |
11 |
> version check. |
12 |
|
13 |
That too, no doubt about it, but that doesn't invalidate what Mike |
14 |
already said. |
15 |
|
16 |
> And again, downgrade of dependencies it is not against any rule which |
17 |
> would justify mask and removal. |
18 |
> |
19 |
> Another example from the X.org packages, installing the proprietary |
20 |
> ATI/NVidia drivers will cause downgrades for xorg-server on ~arch |
21 |
> systems. Nobody in his right mind is proposing to treeclean them because |
22 |
> of this. |
23 |
> |
24 |
|
25 |
The new xorg-servers could get package.masked until these major drivers |
26 |
are available. |
27 |
Albeit, I'm not intrested in pursuing this since with separate |
28 |
xorg-server package, it's the drivers that need rebuilding against it, |
29 |
and the VIDEO_CARDS="" setting is keeping it in certain version until |
30 |
the VIDEO_CARDS="" setting is satisfied. |
31 |
|
32 |
Poor example to make a case. |
33 |
|
34 |
>>>> further, when the newer version gets stabilized and then the older ones |
35 |
>>>> dropped, what then ? your package is broken. |
36 |
>>> |
37 |
>>> Yes, when the older one is dropped _that_ would be reason for |
38 |
>>> masking+removal. However I have not seen any plans of doing so. Actually |
39 |
>>> the current amd64 stable 2.6 versions are 35, 26 and 10 months old |
40 |
>>> respectively, I wouldn't expect that to happen any time soon. |
41 |
>> |
42 |
>> sorry, but that's irrelevant. the lack of tree-cleaning is more due to |
43 |
>> missing automatic generation of ChangeLog files. but if this is going to be a |
44 |
>> sticking point for you, i can simply clean the tree as soon as we get newer |
45 |
>> stable versions. |
46 |
> |
47 |
> If the old versions and reverse dependencies are dropped in accordance |
48 |
> with |
49 |
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#doc_chap7 |
50 |
> then I won't complain. |
51 |
|
52 |
The intresting part of that document is "You should also not cause an |
53 |
unnecessary downgrade for any "~arch" when ..." which also applies to |
54 |
setting dependencies just as well. |