On Sunday 02 October 2011 16:40:18 Chí-Thanh Christopher Nguyễn wrote:
> Another example from the X.org 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.
yes, this does cause issues for some, but i think we're willing to make
exceptions when they're justified -- life isn't black & white after all. the
user base is fairly large enough to accept the downsides here. it's also
proprietary, so we don't have nearly as much chance of getting it fixed.
conversely, i'd put forth that qutecom does not have a user base size to
justify causing misbehavior (too bad we don't have installed package
statistics to provide some data here), and the fact that it's open source
means it should get fixed or get punted.
otherwise, Rich summed up things nicely in his later post.
> >> 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 use of "surprise" can be flexed here. yes, you were surprised it was
punted, but that doesn't make it a "surprise treecleaning" to the larger
community. the package has had an open bug for a while, was announced that it
was going to be removed, and was cleaned ~17 days after the announcement.
> The second time the package was removed was even without mask or
well, it shouldn't have been re-added in the first place
> >>> 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
> c_chap7 then I won't complain.
i would not consider broken packages (i.e. qutecom) in the tree as basis for
retaining the old versions of linux-headers. your package is already broken,
and removing the linux-headers would break that depgraph.