At 5:39 PM -0400 7/14/00, Garrett Wollman wrote:
>Around here, we have a convention that each printer has a record
>in the DNS for printername.lpd-spooler which points to the print
>server for that printer.  It occurred to me that, if there are no
>local printers, no additional information is needed for lpr and
>lpd to operate -- thus obviating the need for that pesky
>`/etc/printcap' file which never seems to be stay up-to-date.

and in the update, he wrote comments which said:
>   This is intended for large sites where distributing the
>   printcap file is a pain; it will infer from the presence
>   of spool directories in _PATH_DEFSPOOLDIR a printcap entry
>   with rm=%s.lpd-spooler and rp=%s (following the convention
>   used at MIT-LCS where the author currently works).

I can sympathize with the idea of getting rid of /etc/printcap,
but I admit this strategy perplexes me.  How is it easier for
you to keep the "presence of spool directories" up to date, than
it is to keep /etc/printcap up-to-date?  Speaking for my lpd use
here at RPI, it is MUCH easier for us (RPI) to keep printcap files
in sync than it is to rely that the contents of a directory on the
local hard disk is magically correct.

Further, if you really CAN keep that up-to-date easier, then it
seems to me pretty trivial to write some perl script or routine
in chkprinter which simply creates /etc/printcap from those
directories.  From my reading of your update, you have this
"synthetic" printcap file which lpd knows about, but you never
write that out anywhere.  At least at RPI, we do have other
processes which check the /etc/printcap file to make decisions.
If that file does not exist, or is not accurate, then those
other processes will not work right.

I would also say that here at RPI (at least), we have plenty
of things in the printcap entries which are not covered by
this strategy.  Most notably, printer aliases.  Every printer
we have has multiple names.  How are multiple names handled
in this situation?

Obviously I am just writing the first things which come to my
mind in ten minutes of me looking at this update (late on a
friday evening!), but it strikes me that this is too much a
matter of codifying into freebsd's lpd something which is
rather specific to MIT practices.  This may very well be useful
for other people too, but I can't imagine how I would make any
use of this at RPI.

That by itself is not important, but (if I am reading your update
correctly) it means that there are now "two ways" that the code
will deal with printcap files.  When someone makes an update (such
as adding new fields to 'struct printer'), they will have to be
sure to make the update in both places.  This makes me queasy.

Also, I wonder how all this fits in with the discussion in -arch
which has been going (on and off) about replacing lpr in FreeBSD
with lprNG.  That's not my idea, but I do know I have been
holding off some lpr/lpd updates of my own until I have some idea
what is going to happen with that.  If freebsd is going to switch
to lprNG, then this is just one more little oddity which (I think)
lprNG will not handle quite the same way.

Me, I am interested in ways to make printcap files more automated,
but this strategy which may work well in MIT's environment would
not make any sense in ours...

Disclaimer Reminder: I've only SKIMMED through the actual update,
so I may misunderstand what it's doing...  Apologies if I have
done that.

Garance Alistair Drosehn           =   [EMAIL PROTECTED]
Senior Systems Programmer          or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to