| 1 |
On Sunday, October 02, 2011 16:00:30 Chí-Thanh Christopher Nguyễn wrote: |
| 2 |
> I agree that a downgrade is a bit inconvenient for users. But if another |
| 3 |
> package is built later with DEPEND on newer linux-headers or emerge |
| 4 |
> --deep option, then it will get upgraded again. As no package runtime |
| 5 |
> depends on it, the system will not function any worse with old |
| 6 |
> linux-headers. |
| 7 |
|
| 8 |
the system is functioning wrongly because you're forcing users to needlessly |
| 9 |
upgrade/downgrade packages. in addition, packages in the tree aren't the only |
| 10 |
things to be considered. if the user is building code that works fine against |
| 11 |
the latest stable, but your package forced it to downgrade, they might no |
| 12 |
longer build correctly. |
| 13 |
|
| 14 |
> I propose that if linux-headers maintainers want to make downgrades |
| 15 |
> "illegal" (as the new summary to bug 361181 suggests) or restricted in |
| 16 |
> some way, they do so in policy or code. |
| 17 |
|
| 18 |
this has nothing to do with linux-headers. causing *any* other package to go |
| 19 |
through upgrade/downgrade cycles is bad. as Samuli said, this is pure common |
| 20 |
sense. i'm not sure why we need to explicitly spell this out. |
| 21 |
|
| 22 |
> Not by surprise treecleaning of packages. |
| 23 |
|
| 24 |
as you were already shown, this wasn't really a surprise. it went through the |
| 25 |
normal announce process, albeit not the normal 30 day grace period. |
| 26 |
|
| 27 |
> > further, when the newer version gets stabilized and then the older ones |
| 28 |
> > dropped, what then ? your package is broken. |
| 29 |
> |
| 30 |
> Yes, when the older one is dropped _that_ would be reason for |
| 31 |
> masking+removal. However I have not seen any plans of doing so. Actually |
| 32 |
> the current amd64 stable 2.6 versions are 35, 26 and 10 months old |
| 33 |
> respectively, I wouldn't expect that to happen any time soon. |
| 34 |
|
| 35 |
sorry, but that's irrelevant. the lack of tree-cleaning is more due to |
| 36 |
missing automatic generation of ChangeLog files. but if this is going to be a |
| 37 |
sticking point for you, i can simply clean the tree as soon as we get newer |
| 38 |
stable versions. |
| 39 |
|
| 40 |
> > skipping 30 days is a bit premature, but re-adding it at this point |
| 41 |
> > doesn't make sense. fix it and re-add it, or don't re-add it at all. |
| 42 |
> |
| 43 |
> That seems to be the only sensible solution at this point. I will |
| 44 |
> probably find time next week or so to create and test a new ebuild. |
| 45 |
|
| 46 |
sounds great |
| 47 |
-mike |
Archives