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

Re: Overall bitrot, package reviews and fast(er) unmaintained package removals

+++ Ondřej Surý [2016-04-06 00:18 +0200]:
> Hey,
> while doing some work on PHP transitions, saving courier-imap, finally
> packaging seafile since they finally stopped violating GPL, I found a
> quite a lot of bitrot in some (mostly leaf) packages. Packages untouched
> for years after initial upload, packages with unreachable maintainers,
> etc[1].

As a porter I've seen a lot of this too. 
> I have a feeling that we are hoarding packages, but the overall quality
> varies a lot (not pointing fingers here). The feeling I have now was
> same when I was doing Berkeley DB transition (and I really wish I just
> filled couple more ROMs/RQAs then instead of fixing the outdated
> software in the archive).

Well, I don't think it's necessarily bad when someone who has nothing
to do with the package just fixes an issue they know about (I've done
quite a lot of 'make dh_autoreconf work' and 'make multiarch work' and
'make cross-building work' NMUs for example, as well as more specific
'make work on arm*' uploads). It's understandable that maintainers
often ignore that stuff because they don't understand it, and don't
want to break things.

What I don't know is whether anyone in the world actually uses this
software or cares about it, and the relative benfits of updating it or
removing it. Am I completely wasting my time fixing up some old package
that doesn't build on arm64?

> * Not really sure if we have packages so "rock-stable" that they still
> work even though they haven't been touched in years,

I think we do have some of these, but I don't know which ones they

What is frustrating about largely-unmaintained software is that it
would often be much quicker and easier to fix most of the issues by
throwing away the old packaging and just making it a dh package (or
even debhelper at all). But this is strongly discouraged in NMUs, so
adds a lot of work for porters, who have to do things the hard way,
and in an old package often find a load of other things have broken
along the way so you have to fix those too in order to upload (here is
a good example where what should have been applying a simple
autoreconf patch led to a rabbit-hole of woe due to accumulated FTBFS
problems with new gcc and java
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755840 )

openvrml used to be important, but maybe it's not worth the effort to
fix anymore (although I've now done 90% of it - if someone did the
last 10% it'd be good for another release at least). It does seem
clear that the maintainer isn't taking much/any notice.

> * Some automated check that would mark the package as outdated. 

I would certainly find this useful as some kind of metric.  I'm not
sure I agree with all your scoring items in detail, but they are clearly

We have got a lot of cruft, and perhaps removing some of it is
actually sensible use of people's time.

> .. perhaps be more aggressive in
> removing software that's no longer useful and just lies in the archive
> dormant.

The fact that Debian has a lot of software is a genuine benefit. Just
because stuff is old, does not mean it is no longer useful. The
problem is that we don't really know how to distinguish between
old-and-just-cruft and old-and-still-handy.

I do agree that we could remove more than we currently do, probably with very
little real fallout, and a corresponding increase in overall quality.

Principal hats:  Linaro, Debian, Wookware, ARM

Attachment: signature.asc
Description: Digital signature

Reply to: