Russ Allbery wrote...
> Since I wrote my original message, I noticed that rlpr is orphaned.
If only rlpr were the only one :-|
When looking into the reverse dependencies of lpr/lprng at the beginning
of this thread, I found several orphaned packages, some for already for
more than ten years. To name a few:
* lprng
* apsfilter(D)
* e2ps(R)
* ifhp(R)
* magicfilter(R)
* tk-brief(R)
* trueprint(R)
* xhtml2ps(S)
Plus those NMU-only-maintained packages where the maintainer is probably
MIA.
That's not surprising: lpr is an old technology, it may be simple but it
has quirks. People moved on, and if they cared a little, they let go.
(...)
> If anyone else who still prints
> regularly prefers the simple command-line interface, you may want to
> consider adopting it, although it looks like you're likely to have to
> adopt upstream as well since it seems to have disappeared.
Dead upstream applies as well to most of the packages listed above. And
that brings me to another, bigger question:
Do we provide our users a good service if we keep such zombies alive
for such a long time?
What I'm trying to say: All the maintenance that happens to such
packages is on an emergency base. If some changes (policy, debhelper,
stricter gcc checks, etc.) trigger RC bugs, someone might do the
necessary adjustments, also because it's often a low-hanging fruit. But
regular care does not happen, and after a few years it shows.
Plus, most of that code is in C, and I take the liberty to state they
all have security issues. They are just unknown, because no one bothered
to take a closer look. But these bugs exist simply because twenty and
more years ago, secure programming wasn't that common.
When kicking isdnutils out of Debian (since Linux kernel hat dropped the
support) I coined the phrase that Debian is not a museum. The lpr/lprng
area feels like it.
On the other hand, becoming museal is a natural result of how we do
things in Debian: Packages are kept alive as long as one single person
cares, while their interest might rather be eliminating RC bugs than the
actual functionality. And proposing a cleanup like in this thread
reliably triggers negative reactions of a few people who want to keep
it.
Without an external limitation (mostly specific hardware) it's hard to
draw a line when it's obviously the time to remove near-dead packages,
at least from the stable releases. I don't have a good idea either what
to do here. 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". And please
don't promote that, it's obviously flawed. But I'm left with a bad
feeling how things currently are.
Chri- "Might do an abandonware BoF at next DebConf" stoph
Attachment:
signature.asc
Description: PGP signature