This is a good idea ! There is a lot of cruft, especially packages created for
some obscure reason 2-3 years ago and since then abandoned both by the
maintainer and by upstream, and superseded by the next cool thing in the nodejs
I propose to extract from UDD a list of candidate packages to be removed: those
not fulfilling the criteria proposed by Jérémy, plus some more like:
- popcon > 20
The list would be published for scrutiny here in this mailing list or on the
wiki for say 2 weeks.
To address the point raised by Ben (i.e. to make sure we don't remove a library
needed at some point in the future for some other package not yet uploaded), I
would leave it to the owner of the high-level package IPTs: for each of those
there is a Task in the wiki or a non-disclosed WIP list - in any case the ITP
owner knows best and she should manually remove from the list the packages she
thinks she'll need, providing a rationale (i.e. "needed for yarnpkg").
Once the 2 weeks are over we can proceed mass filing those "candidate for
Once the additional 2 weeks are over the bugreports can be reassigned to
On 28/01/2017 10:17, Jonas Smedegaard wrote:
> Quoting Ben Finney (2017-01-28 03:07:01)
>> Jérémy Lal <kapo...@melix.org> writes:
>>> - or having a reverse (build-)dependency, or what's the point ?
>> I am very much in favour of this: node libraries should be in Debian
>> to provide a library that is needed for some actual program of benefit
>> to Debian users.
>> But my eagerness to remove useless packages makes me worry that some
>> useful ones could be swept up also.
>> One use case I don't see addressed: How will we ensure that a library
>> is not needed for some other package not yet uploaded to Debian?
> Removal from testing involves filing a bugreport to ftpmaster. I guess
> it makes sense if at all uncertain to first file bugreport against the
> package and cc this list - of not-to-high severity - suggesting the
> intent (removal from stretch or removal from Debian completely) some
> time (2 weeks?) before reasigning to ftpmaster.
> Discussing only here is not adequate: Being part of this team and
> subscribing to this mailinglist is voluntary.
> - Jonas