| 1 |
On 10/29/2016 02:30 PM, Kristian Fiskerstrand wrote: |
| 2 |
> On 10/29/2016 07:59 PM, NP-Hardass wrote: |
| 3 |
>> On 10/08/2016 07:57 AM, Pacho Ramos wrote: |
| 4 |
>>> # Fails to build (#515294), nothing needs it, relies on obsolete |
| 5 |
>>> capi4kutils. |
| 6 |
>>> |
| 7 |
>> |
| 8 |
>> For all the packages being removed due to capi4kutils, how many were |
| 9 |
>> investigated with net-libs/libcapi? For WINE, we transitioned to using |
| 10 |
>> libcapi instead of capi4kutils, and I don't see why some of those |
| 11 |
>> couldn't as well, provided the capi4kutils is the only reason why those |
| 12 |
>> are being treecleaned. |
| 13 |
>> |
| 14 |
> |
| 15 |
> Someone needs to take over responsibility for the packages |
| 16 |
> (maintainership) and fixing the issues then. If not, they should be removed. |
| 17 |
> |
| 18 |
|
| 19 |
I'm only talking about the packages that have no other issues and are |
| 20 |
only being treecleaned because of this dependency. Honestly, I don't |
| 21 |
care about any of those packages. I only brought this up because |
| 22 |
sometimes it is better to only treeclean when appropriate, and if |
| 23 |
switching from one dep to another (which should have been virtual'd) |
| 24 |
resolves it, it might not still meet the conditions for tree cleaning. |
| 25 |
We don't normally tree clean packages simply because they are old or |
| 26 |
don't have a maintainer. |
| 27 |
|
| 28 |
So, I will reiterate my one and only point, for those that are only |
| 29 |
being removed due to the removal of capi4kutils, how many are still |
| 30 |
worthy of being treecleaned after swapping out that dep? |
| 31 |
|
| 32 |
If you feel that is too high a maintenance burden, fine, remove them |
| 33 |
all. I'm merely proposing it be looked at since otherwise we are |
| 34 |
potentially removing packages that don't have to or shouldn't be removed. |
| 35 |
|
| 36 |
-- |
| 37 |
NP-Hardass |
Archives