Re: Foomatic-ability for LPR

[Dennis den Brok <d.den.brok%uni-bonn.de@localhost>]

Johnny C. Lam <jlam%pkgsrc.org@localhost> schrieb:
> Foomatic-rip autodetects the spooling system based on examining the
> environment variables and the options passed to it.  BSD lpd and LPRng
> are treated differently enough within the foomatic-rip script that I
> don't think making our lpd look like LPRng is wise.
>
> If we want to do "just enough" to allow NetBSD's lpd to use foomatic-rip,
> then adjusting lpd(8) to pass -Jjobname to the filter is enough.

The reason I suggested otherwise is that this is quite abusive.
Neither "af" nor "-J" can thus be used the way they are intended
to anymore, i.e., one loses accounting and the ability to specify
an arbitrary job name. I see it is possible to work around this
(though uncomfortably), and both facilities don't seem too important
anyway, I just wanted to discuss publically what the way to go
should be.

> If we want to really allow specifying arbitrary options to the filters
> in the way that LPRng allows, then we should just do it our own way
> and then teach foomatic-rip about this new "nblpd" variant.

I don't think appearing as LPRng is unwise. Maybe I've overlooked
something, but AFAICT, LPRng passes exactly the same options to
filters as NetBSD's lpr, plus possibly some others. Among those,
we'd just need to support "--ppd <pathtoppd>" and "-Z <optionstring>".
Of course, one would have to track changes in the behaviour of both
LPRng and foomatic-rip, but that doesn't seem likely to change in
a way that would break a NetBSD-lpr modified accordingly.

To sum it up, I think it's abusiveness vs. intrusiveness. I don't
have a strong opinion (which doesn't count anyways), but slightly
prefer intrusiveness over abusiveness.

Regards,

--
Dennis den Brok