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:
pgpd3i9wEpvgd.pgp
Description: PGP signature