| 1 |
On Sunday 02 October 2011 16:40:18 Chí-Thanh Christopher Nguyễn wrote: |
| 2 |
> Another example from the X.org packages, installing the proprietary |
| 3 |
> ATI/NVidia drivers will cause downgrades for xorg-server on ~arch |
| 4 |
> systems. Nobody in his right mind is proposing to treeclean them because |
| 5 |
> of this. |
| 6 |
|
| 7 |
yes, this does cause issues for some, but i think we're willing to make |
| 8 |
exceptions when they're justified -- life isn't black & white after all. the |
| 9 |
user base is fairly large enough to accept the downsides here. it's also |
| 10 |
proprietary, so we don't have nearly as much chance of getting it fixed. |
| 11 |
conversely, i'd put forth that qutecom does not have a user base size to |
| 12 |
justify causing misbehavior (too bad we don't have installed package |
| 13 |
statistics to provide some data here), and the fact that it's open source |
| 14 |
means it should get fixed or get punted. |
| 15 |
|
| 16 |
otherwise, Rich summed up things nicely in his later post. |
| 17 |
|
| 18 |
> >> Not by surprise treecleaning of packages. |
| 19 |
> > |
| 20 |
> > as you were already shown, this wasn't really a surprise. it went |
| 21 |
> > through the normal announce process, albeit not the normal 30 day grace |
| 22 |
> > period. |
| 23 |
> |
| 24 |
> The whole process was a surprise to me because the masking and |
| 25 |
> treecleaning happened while I was on 20 days of devaway. I leave the |
| 26 |
> away message for a day more in case anyone wants to verify. |
| 27 |
> |
| 28 |
> And it was a surprise treecleaning because the mask and policy said 30 |
| 29 |
> days, but the removal happened before the 30 days were over. |
| 30 |
|
| 31 |
the use of "surprise" can be flexed here. yes, you were surprised it was |
| 32 |
punted, but that doesn't make it a "surprise treecleaning" to the larger |
| 33 |
community. the package has had an open bug for a while, was announced that it |
| 34 |
was going to be removed, and was cleaned ~17 days after the announcement. |
| 35 |
|
| 36 |
> The second time the package was removed was even without mask or |
| 37 |
> announcement. |
| 38 |
|
| 39 |
well, it shouldn't have been re-added in the first place |
| 40 |
|
| 41 |
> >>> further, when the newer version gets stabilized and then the older ones |
| 42 |
> >>> dropped, what then ? your package is broken. |
| 43 |
> >> |
| 44 |
> >> Yes, when the older one is dropped _that_ would be reason for |
| 45 |
> >> masking+removal. However I have not seen any plans of doing so. Actually |
| 46 |
> >> the current amd64 stable 2.6 versions are 35, 26 and 10 months old |
| 47 |
> >> respectively, I wouldn't expect that to happen any time soon. |
| 48 |
> > |
| 49 |
> > sorry, but that's irrelevant. the lack of tree-cleaning is more due to |
| 50 |
> > missing automatic generation of ChangeLog files. but if this is going to |
| 51 |
> > be a sticking point for you, i can simply clean the tree as soon as we |
| 52 |
> > get newer stable versions. |
| 53 |
> |
| 54 |
> If the old versions and reverse dependencies are dropped in accordance |
| 55 |
> with |
| 56 |
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#do |
| 57 |
> c_chap7 then I won't complain. |
| 58 |
|
| 59 |
i would not consider broken packages (i.e. qutecom) in the tree as basis for |
| 60 |
retaining the old versions of linux-headers. your package is already broken, |
| 61 |
and removing the linux-headers would break that depgraph. |
| 62 |
-mike |
Archives