[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: lprng as 'stantard' package (was: Re: Test packages for libc6 2.1.91+cvs)



On Wed, 12 Jul 2000, Josip Rodin wrote:
> On Wed, Jul 12, 2000 at 09:59:54AM +0200, Matthias Klose wrote:
> >  > LPRng could go into standard, its reasonably stable except for the last
> >  > month or so (and that appears in the unstable dist).  I still not exactly 
> >  > happy with the post/pre inst/rm scripts but they should be largely stable.
> > 
> > Is there a formal procedure to put a package in standard? cupsys could
> > go to standard as well.

I'd guess reaching a concensus in debian-devel first is a must if you want
your package to go standard.

BTW, AFAIK one should not have conflicting packages as "standard", which
means one of lpr, lprng or cupsys is standard and all others are "extra".
Right now lpr is standard, and lprng is extra, and cupsys is optional.

Also, shouldn't cupsys (and most importantly, cupsys-bsd) be priority extra?
cupsys-bsd conflicts with a standard package, and it doesn't make much sense
(to me :-) ) to have cupsys with one priority and cupsys-bsd with another.

Something else to keep track of: if lprgn goes standard, anything
conflicting with it must go extra.

> % apt-cache show lpr lprng cupsys | grep ^Size
> Size: 85766
> Size: 894722
> Size: 2298766
> 
> Nice :<
 
Yes, that's something to be taken into account as well... Jeez, one order of
magnitude difference in sizes?

However, 800kb isn't TOO big. I'd rather ask which one is easier to setup
(out of the box), is more interoperable and is safer (as in more secure
after the postinst script has done its job)?

For me, size was not really a very major concern when dumping lpr for lprng
due to usability issues (I know from experience that lprng is much better
behaved when dealing with administrating remote requests than lpd is). Since
lpr is NOT in the base system, does the tenfold increase in size matter
enough as to make lprng not the standard lpr daemon?

Now, for cupsys: 

As a regular user, I know lprng is up to the task. I've used it for a
reasonable time, after all. Is cupsys stable and proven enough to become
standard right now, or would it benefit of a bit more time for settling
down? (Also, when do we get the new upstream CUPS 1.1? packaged :-P)

There is some stuff about "adduser" having a bug which makes cupsys
installation sub-optimal in the readme. Has this bug been fixed yet? If it
was fixed, why wasn't the readme.debian (and possibly the postinst scripts)
updated?

Is it compatible enough with old lpd-compatible daemons and printers, or are
there interoperation problems? Does it offer drop-in compatibility with a
stant-alone GS as a driver (and the 'magic' printer filter packages in
debian)? If not, cupsys is not a good choice for being standard. Using GS as
an output driver (or as I like to say, PostScript(tm) support for the poor
(like me :^P) ) is a must, and an embebbeded old GS does not cut it (as well
as being a severe waste of space and a very non-unixy thing to do).

cupsys seems an interesting package (and printing system). But to *me* it
looks like it might need some work (both upstream and in the package) before
being a good choice for standard. It's a good thing to have in Debian,
though. 

I quite like the capability of specifying driver options with the job
(instead of multiple queue hacks for lprng/lpr + GS), and just because of
that I'll add trying out cupsys to my forever growing to-do list. A
well-integrated stand-alone GS + CUPS would be a major neat thing to have
(if such a thing is possible, that is). Expect a stream of wishlist bugs
(and if we're lucky, patches) if I ever get to it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Attachment: pgpdPZXXMi42S.pgp
Description: PGP signature


Reply to: