Re: The future of lpr and lpd

On Sat, Feb 21, 2026 at 12:32:02PM +1100, Greg 'groggy' Lehey wrote:
> On Friday, 20 February 2026 at 19:39:49 +0100, Dag-Erling Smørgrav wrote:
> > Due to low code quality, known bugs, and a general lack of interest
> > over the past several decades, we are currently considering retiring
> > the entire lp* suite (lp(1), lpc(1), lpd(8), lpq(1), lpr(1),
> > lprm(1), lptest(1), pac(8)) from base.
> 
> As others have noted, "if it ain't broke, don't fix it".  Clearly it
> *is* broke, but you're replacing it, not fixing it.  And who are "we"?
> And why are you removing it rather than replacing it?

"we" is srcmgr@, or at least, that's where the discussion started.

Dag-Erling has indeed done the rather tedious work to fix the bugs which
prompted the original announcement.  I believe he does not wish to
further maintain these utilities, and someone with the time and ability
to maintain or replace them has plenty of time to step up.

> > It would be extremely helpful if those of you who are using base lpr /
> > lpd today could take the time to try out the lprng package / the
> > print/lprng port (which should be a drop-in replacement) and let me know
> > if there is any loss of functionality.
> 
> OK, good that you have done this.  Did you coordinate (or at least
> discuss) this with the other BSDs?
>
> And why a new name?

It is not the same code.

> We didn't change "FreeBSD" to "FreeBSDng" when we
> released 5.0 decades ago.  And IIRC some other utilities have been
> replaced with rewrites, without the name changing.  And then there are
> things like postfix and cups (shudder) that reuse the old names.  So
> if it HAS to be a port, why not call it print/lpr?  If it isn't 100%
> compatible (think of names hard-coded in scripts), what is the
> difference?  Why?  And in which version of ports is print/lprng?  I
> don't find it in my tree.

Dag-Erling is referring to sysutils/LPRng, I believe.

> Once an argument for FreeBSD was that it installed with all tools out
> of the box.  Removing things from base just moves towards the Linux
> view of the world.

This argument only holds so long as developers are actively maintaining
said things from base.  At a minimum, this consists of handling bug
reports and making sure that a reasonable baseline of code quality is
maintained.