[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Abandonware in testing (Re: lpr/lpd)

On 2023-09-23 08:35 +0200, Gioele Barabucci wrote:
> On 22/09/23 09:41, Christoph Biedl wrote:
> > I doubt simple rules will really work out, rules like that
> > one I had in mind "Packages are removed from testing once they have been
> > orphaned/last maintainer-uploaded more than five years ago".
> Maybe something more nuanced may work.
> For example: packages are removed from testing if:
> - have been orphaned/last maintainer-uploaded more than 2 releases ago,
> - have no autopkgtests OR autopkgtests fail OR are not
> lintian/piuparts-clean.

I don't think that 'maintainer-uploaded' rules is a good one for capturing 'is looked after' whichis what I think you intended. 

For example, the very useful package ncdu (which I just sponsored an
NMU upload of - 1.19 is currently in DELAYED) would fail this test.

It's actually quite well-maintained, just not by the maintainer:
someone else has uploaded the last 3 upstream versions via
debian-mentors. Upstream even took debian patches in the last release
so there are now no patches, which is about as good as things get for
mature software.

Only-NMU uploads for some years is quite a common pattern and whilst
sometimes it indicates the package is only getting emergency
drive-by maintainance, sometimes (like here) the thing is actually being
maintained just as it should be (just by someone who is not officially
the maintainer).

In this case looking for NMUs of new upstream versions would give the
clue that this is not just life-support. I don't know if that is a
sufficient rule?  Repeated NMUs by one person is also a clue. As you
say something 'more nuanced' still is needed and a useful test may
actually be quite complicated.

To get back to the wider issue: In general I like the fact that Debian
doesn't remove packages so long as they still work (so fas as we
know). It's one thing that gives users stability. (I'm still grumpy
about ipmasq being removed circa 2011, and I still use a local build
of 'bins' which was removed in 2015).

But we do end up carrying a lot of old stuff, possibly some of
which is genuinely superceded/no longer used.

And as a user I _would_ like better mechanisms to explain when
$something has been replaced by $something-else and users are expected
to move over at some point. Sometimes on upqrade a package has just
gone and it's not something you know anything about so you have no
idea if there is a replacement of some sort or what it might be
called. apt-listchanges can fill this gap, but only if you install it
(and it's kind of annoying because it interrupts the install/upgrade
process). And this only works for well-maintained packages that
actually update Debian.NEWS, not barely-maintained/unmaintained
packages. I guess you might get the info from the replacing, as
opposed to replaced package, but as with printing it's often a whole
set of stuff and it's not clear where any 'moving on' info should live. 

Principal hats:  Debian, Wookware, ARM

Attachment: signature.asc
Description: PGP signature

Reply to: