On Thu, Mar 20, 2003 at 02:39:07PM -0600, Frederick Bruckman wrote:
> On Thu, 20 Mar 2003, Greywolf wrote:
> 
> > I think the point being brought up here is "why don't we wrapperize
> > <x> to prevent third-party pre-emption of system utilities?" (MTA, DNS,
> > printing, curses, the list could go on).
> >
> > To which, of course, the answer is that any utility that seeks to install
> > itself wholesale in the same place as a system utility is at best
> > pompously designed and at worst brain damaged.
> >
> > If we wrapperise EVERYTHING, we invite third party packages to be
> > horrifically abusive to an otherwise sane system, and I, for one,
> > do not think this is a well-advised move.  If we do CUPS, what next?
> 
> Yes, that clearly expresses the point I was dancing around. I too have
> a problem with sending people to pkgsrc for every need, even while I
> recognize our userland getting old and frayed. (We have one window
> manager, no mime tools, but "fsplit" and "lkbib"? Who uses those?)

But the fact is that many people prefer out-of-tree software. Providing
the option to easily integrate a different lpd into a NetBSD system
doesn't mean that you have to start encouraging people to use a different
lpd, but it gives those who wish to do so an easy solution. Why make it
difficult for them, when the fix is rather trivial? 

And I don't think that programs like CUPS that have binaries of the same
name as the standard utilities are broken or brain damaged. If CUPS is
providing the same service as our lpd, and we want everything to use CUPS
by default, we're (well, not me, I don't use CUPS) stuck relying on paths.
Programs expect to be able to call lpr when printing. What good would CUPS
be if it didn't include utilities of the standard names? You'd have to go
through everything and specify some different CUPSish commands, with
probably different syntax. That would be a mess.

I'm in favor of lpwrapper.

-- 
Soren Jacobsen