Re: lprng as 'stantard' package (was: Re: Test packages for libc6 2.1.91+cvs)
On Thu, Jul 13, 2000 at 11:11:16AM -0300, Henrique M Holschuh wrote:
> 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.
Makes sense. I'll fix this in the next upload.
> 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)
On its way. (I have a beta 3 package here, but there are a few issues
concerning upgrading from 1.0.4 that I need to fix.)
As for "stable" and "proven", all I can tell you is that it works for
me without problems. The code is supposedly based on a commercial
product with many years of history behind it, but it's only been free
for about a year.
> 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?
Haven't checked recently. The bug does not appear to be fixed in
potato, but it is closed, so I assume it's fixed in woody. (It's
actually a bug in adduser that's causing the problem.)
> 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).
We'll see about the GS thing; it seems like it could be possible.
As for lpr compatibility, CUPS 1.1 should be a feature-complete
drop-in replacement for lpr.
> 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.
Thanks. Be my guest; I'll do what I can.
Reply to: