Gentoo Archives: gentoo-dev

From: "Chí-Thanh Christopher Nguyễn" <chithanh@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
Date: Sun, 02 Oct 2011 20:41:03
In Reply to: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild by Mike Frysinger
Mike Frysinger schrieb:
> 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.
Then the code is broken that is built outside portage and does not function correctly with old linux-headers without doing any kind of version check. And again, downgrade of dependencies it is not against any rule which would justify mask and removal. Another example from the packages, installing the proprietary ATI/NVidia drivers will cause downgrades for xorg-server on ~arch systems. Nobody in his right mind is proposing to treeclean them because of this.
>> 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.
The whole process was a surprise to me because the masking and treecleaning happened while I was on 20 days of devaway. I leave the away message for a day more in case anyone wants to verify. And it was a surprise treecleaning because the mask and policy said 30 days, but the removal happened before the 30 days were over. The second time the package was removed was even without mask or announcement.
>>> 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.
If the old versions and reverse dependencies are dropped in accordance with then I won't complain. Best regards, Chí-Thanh Christopher Nguyễn