| 1 |
Mike Frysinger schrieb: |
| 2 |
> the system is functioning wrongly because you're forcing users to needlessly |
| 3 |
> upgrade/downgrade packages. in addition, packages in the tree aren't the only |
| 4 |
> things to be considered. if the user is building code that works fine against |
| 5 |
> the latest stable, but your package forced it to downgrade, they might no |
| 6 |
> longer build correctly. |
| 7 |
|
| 8 |
Then the code is broken that is built outside portage and does not |
| 9 |
function correctly with old linux-headers without doing any kind of |
| 10 |
version check. |
| 11 |
|
| 12 |
And again, downgrade of dependencies it is not against any rule which |
| 13 |
would justify mask and removal. |
| 14 |
|
| 15 |
Another example from the X.org packages, installing the proprietary |
| 16 |
ATI/NVidia drivers will cause downgrades for xorg-server on ~arch |
| 17 |
systems. Nobody in his right mind is proposing to treeclean them because |
| 18 |
of this. |
| 19 |
|
| 20 |
>> Not by surprise treecleaning of packages. |
| 21 |
> |
| 22 |
> as you were already shown, this wasn't really a surprise. it went through the |
| 23 |
> normal announce process, albeit not the normal 30 day grace period. |
| 24 |
|
| 25 |
The whole process was a surprise to me because the masking and |
| 26 |
treecleaning happened while I was on 20 days of devaway. I leave the |
| 27 |
away message for a day more in case anyone wants to verify. |
| 28 |
|
| 29 |
And it was a surprise treecleaning because the mask and policy said 30 |
| 30 |
days, but the removal happened before the 30 days were over. |
| 31 |
|
| 32 |
The second time the package was removed was even without mask or |
| 33 |
announcement. |
| 34 |
|
| 35 |
>>> further, when the newer version gets stabilized and then the older ones |
| 36 |
>>> dropped, what then ? your package is broken. |
| 37 |
>> |
| 38 |
>> Yes, when the older one is dropped _that_ would be reason for |
| 39 |
>> masking+removal. However I have not seen any plans of doing so. Actually |
| 40 |
>> the current amd64 stable 2.6 versions are 35, 26 and 10 months old |
| 41 |
>> respectively, I wouldn't expect that to happen any time soon. |
| 42 |
> |
| 43 |
> sorry, but that's irrelevant. the lack of tree-cleaning is more due to |
| 44 |
> missing automatic generation of ChangeLog files. but if this is going to be a |
| 45 |
> sticking point for you, i can simply clean the tree as soon as we get newer |
| 46 |
> stable versions. |
| 47 |
|
| 48 |
If the old versions and reverse dependencies are dropped in accordance |
| 49 |
with |
| 50 |
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#doc_chap7 |
| 51 |
then I won't complain. |
| 52 |
|
| 53 |
|
| 54 |
Best regards, |
| 55 |
Chí-Thanh Christopher Nguyễn |
Archives