On Thu, 20 Mar 2003, Frederick Bruckman wrote:

> On Thu, 20 Mar 2003, Julio Merino wrote:
>
> > On Thu, 20 Mar 2003 12:06:16 -0600 (CST)
> > Frederick Bruckman <fredb@immanent.net> wrote:
> >
> > Grrrr why did I ever mention cups?  This is not a problem specific with
> > cups.  It is with *any* daemon meant to replace lpd.  Just checked the
> > LPRng package, and it installs the same binaries, so it has the same
> > problem.  And if there is any other alternative, it may be possible
> > affected by this.
> >
> > > explains that you're *expected* to replace your system utilities with
> > > theirs.
> >
> > I don't want to remove or change anything in the base system, as it will
> > be overriden in the next update (no, I don't want to tweak my makefiles
> > nor sources).  Using a wrapper is like "replacing your system utilities
> > with theirs", but in a clean way.
>
> I do see your point. Is there that much of a demand to replace our
> in-tree "lpd"? "sendmail" is positively hated by many, but what's not
> to like about our "lpd"? ;-) ;-)

Just because you and I find lpd to be ok doesn't mean that everyone else
does. I think the fact that we have at least two other printing methods
(CUPS and lprng(?)) indicates that folks are experimenting with new
options.

> > > I'm still afraid that your suggestion will lead to additional
> > > support demands, to the detriment of the very fine (if slightly dated)
> > > in-tree lpd.
> >
> > Like what?  I can't think of anything else needed... (my printing
> > knowledge on *nix is "poor").
>
> Like at worst, people will say, "I see that you're phasing out "lpd",
> so I tried ____, and such and such didn't work", and then folks on the
> lists will try to help them configure ____, and much effort will be
> wasted, and no one will care about our own "lpd" anymore, even though
> it does everything you want a printer daemon to do (namely, spool
> files to the printer :-)). That's my fear, anyway.

I don't think lpwrapper == "I see that you're phasing out 'lpd'".
Supporting other options, yes. Phasing out, no. Well, enabling other
options. I think we can make that clear (and probably should make it
clear) in whatever we document for lpwrapper.

Take care,

Bill