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