+++ 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 are... 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 indicative. 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. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: Digital signature