| 1 |
On 29/10/16 21:25, NP-Hardass wrote: |
| 2 |
> On 10/29/2016 02:30 PM, Kristian Fiskerstrand wrote: |
| 3 |
>> |
| 4 |
>> Someone needs to take over responsibility for the packages |
| 5 |
>> (maintainership) and fixing the issues then. If not, they should be removed. |
| 6 |
>> |
| 7 |
> I'm only talking about the packages that have no other issues and are |
| 8 |
> only being treecleaned because of this dependency. Honestly, I don't |
| 9 |
> care about any of those packages. I only brought this up because |
| 10 |
> sometimes it is better to only treeclean when appropriate, and if |
| 11 |
> switching from one dep to another (which should have been virtual'd) |
| 12 |
> resolves it, it might not still meet the conditions for tree cleaning. |
| 13 |
> We don't normally tree clean packages simply because they are old or |
| 14 |
> don't have a maintainer. |
| 15 |
> |
| 16 |
> So, I will reiterate my one and only point, for those that are only |
| 17 |
> being removed due to the removal of capi4kutils, how many are still |
| 18 |
> worthy of being treecleaned after swapping out that dep? |
| 19 |
> |
| 20 |
> If you feel that is too high a maintenance burden, fine, remove them |
| 21 |
> all. I'm merely proposing it be looked at since otherwise we are |
| 22 |
> potentially removing packages that don't have to or shouldn't be removed. |
| 23 |
> |
| 24 |
Whilst this may potentially be a contentious topic (and one that g-p-m |
| 25 |
has partially attempted to address) there has been a mildly aggressive |
| 26 |
policy applied to treecleaning, whereby if something is old and missing |
| 27 |
a maintainer and/or has even minor issues it is likely be nuked without |
| 28 |
so much as anyone attempting to solve the issues. Granted, all too often |
| 29 |
there IS nobody to address any issues, or outstanding bugs, but I too am |
| 30 |
somewhat of the opinion that if a package builds, has some form of |
| 31 |
upstream source, does NOT have any security vulnerabilities, it should |
| 32 |
live in the main Gentoo tree. This doesn't seem to be a view shared by |
| 33 |
all, but there appears to be a bias to remove and potentially re-add |
| 34 |
later, than maintain what we have properly. |
Archives