Mike Frysinger schrieb: > On Sunday, October 02, 2011 08:58:19 Chí-Thanh Christopher Nguyễn wrote: >> Samuli Suominen schrieb: >>>> Please point to existing authoritative documentation which says that >>>> downgrades are unacceptable. >>>> >>>>> It is NOT gentoo-x86 compatible package in it's current form. >>>> >>>> It sets correct dependency on an existing ebuild in tree. The dependency >>>> is only build time, users can upgrade linux-headers again afterwards. >>>> The application itself is v4l2 compatible. >>> >>> common sense... >>> >>> http://bugs.gentoo.org/show_bug.cgi?id=311241#c2 >>> http://bugs.gentoo.org/show_bug.cgi?id=311241#c5 >> >> linux-headers is not a library, it is strictly a build time dependency >> for all packages which I am aware of. > > forcing downgrades of random packages is extremely poor behavior. it doesn't > matter if it's DEPEND or RDEPEND behavior. if your one package is the last > thing to get installed, then you leave the system in a poor state.
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. 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. Not by surprise treecleaning of packages. > 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. > 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. Though I must say that allowing this clear policy violation to stand while I don't see any policy violation in my ebuild leaves a bad impression. Best regards, Chí-Thanh Christopher Nguyễn
