Re: How to get rid of unused packages (Was: proposed MBF: packages still using source format 1.0)
On Wed, Mar 16, 2022 at 02:11:09PM +0100, Andreas Tille wrote:
>...
> I'm not sure whether there are any PalmPilot devices out there. At
> least the actual *votes* in popcon[1] is down to zero now.
This is less convincing than it sounds, since popcon data is based only
on a tiny and non-representative fraction of our users.
You cannot claim a package is unused solely based on popcon data.
Debian Med also has packages with zero popcon votes, users of software
for exotic/ancient hardware or uncommon usecases (like Debian Med) are
not generating high popcon numbers.
> The package
> was not uploaded by its maintainer for >10 years. It received an NMU by
> Adrian Bunk (in CC as well):
>
> [2022-01-02] imgvtopgm 2.0-9.1 MIGRATED to testing (Debian testing watch)
> [2021-12-27] Accepted imgvtopgm 2.0-9.1 (source) into unstable (Adrian Bunk)
> [2011-02-23] imgvtopgm 2.0-9 MIGRATED to testing (Debian testing watch)
> [2011-02-13] Accepted imgvtopgm 2.0-9 (source i386) (signed by: Erik Schanze)
>
> The changelog of that NMU was:
>
> * Non-maintainer upload.
> * debian/rules: Add build-{arch,indep}. (Closes: #999003)
>
>
> >From my naive perspective this package caused some work from a quite
> busy maintainer for no obvious user base. May be I'm wrong in this
> specific case but this observation raises my question: Do we have any
> means to get rid of packages that should be rather removed from the
> distribution than draining resources.
You are getting it wrong what was draining the resources.
It was not the package that was draining the resources,
it was the MBF that was draining the resources.
And these MBFs usually fail to make a convincing case that the benefits
are worth all the resources that are drained by the MBF.
> If the answer is no should we possibly use the list of packages that are
> not topic of the heated debate around the source format 1.0 (where
> maintainers are obviously are caring about their packages just disagree
> with format 3.0 format) to pick some packages that should be rather
> removed than fixed?
How do you define "rather removed"?
According to the BTS there was and is no known user-visible problem in
the package that needed or needs fixing in the package you are using
as example.
I am still a regular user of my 15 year old iPod, and I was pretty
annoyed when I had to do an emergency adoption (changing nothing but the
maintainer field) of a package I use for it after seeing that someone
thought it would be a good idea to do "RM: RoQA; Upstream not active, orphaned".
As DD I can do that if I notice, the average user cannot do anything and
won't even notice until the next release in 1.5 years.
I do consider it a regression when we no longer ship a package in a
release that was in the previous Debian release.
It is not a problem for us to continue shipping imgvtopgm.
And that's why I'd like to see a case made why it is better for our
users when a package is no longer shipped.
It might or might not be possible to make the case for removal of this
specific package, but "low popcon" or "abandoned upstream" alone are not
convincing points.
> Kind regards
>
> Andreas.
>...
cu
Adrian
Reply to: