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

Re: lpr/lpd


On 9/22/23 16:41, Christoph Biedl wrote:

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.

Erm. We're talking about printers here. lpr is the protocol with the fewest quirks.

I agree that the desktop users have moved on, and they will move on to whatever we present them as default next.

But I also think there are quite a few installations that still use these packages, and where people don't have much of an issue with the packages being effectively NMU-maintained, because their system works, and change only brings uncertainty -- especially if it is change towards something that is "actively" maintained and constantly updated.

My suspicion is that a lot of these installations will have a heavy amount of homebrew scripting added to them, so supporting them from a newer printing system would mean creating a bug-compatible emulation, which we can all agree is a forever maintenance burden unless you also have a plan to migrate these users to a legacy-free environment.

     Do we provide our users a good service if we keep such zombies alive
     for such a long time?

Yes and no. We're providing a better service than pulling the rug under the users, but we could do better by communicating that these packages are in need of new maintainers instead of waiting for them to bit-rot to a point where we have an excuse to remove them -- because all we're doing that way is justify the rug pull, but the impact for the users isn't minimized.

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.

It is simple, straightforward code with a service record of over twenty years, and I remember that we had security researchers back then and there were several advisories on bugtraq for lprng.

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.

Same. I think that it cannot be solved on a per-package basis, instead we might need infrastructure.

One thing I'd think might help would be a tag in the package database that is derived from WNPP status, which would allow the summary output at the end of installs also list packages that are installed that are currently in RFA or O state.

I believe we used to have a tool for that in Debian, but almost no one had it installed because it had additional overhead, making it pointless.


Reply to: