| 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. |
Archives