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

cupsys (was: Re: lprng as 'stantard' package)

(Robert, FYI your last message's signature didn't verify). 

(CCed to cupsys maintainer, so as to get his ideas on the 'wishlist' stuff
at the end of this email without filling out bugs)

On Fri, 14 Jul 2000, Robert Bihlmeyer wrote:
> Josip Rodin <joy@cibalia.gkvk.hr> writes:
> > % apt-cache show lpr lprng cupsys | grep ^Size
> > Size: 85766
> > Size: 894722
> > Size: 2298766
> > 
> > Nice :<
> First, cups provides more than the other printing packages. It can
> print postscript to non-PS printers out of the box, and seems to
> include some version of GhostScript for that. If one subtracts out the

Yes, and that's my grip with it so far. Unless the code HAS to include a
modified GS instead of interfacing to an installed GS for a very, very good
**technical** reason, that's a rather ugly way to solve a problem. 

Besides, something called the Common UNIX Printing System HAS to follow the
Unix way, ne? That means piping through GS, not including it... even if it
would require extending GS' external interfaces upstream, or writing a CUPS
driver for GS.

I notice this 'include and extend' thinking was used for the PDF conversion
(more duplicated code for distributions) instead of requiring the xpdf
utility and using a wrapper script. What now, will they include dvi2ps in
there next? Argh. I really hope there's a good reason for all this.

> included GS stuff (binary, additional .ps files, fonts) that weighs in
> with 2345 kB that leaves 1608 kB, which is already less than the
> installed size of lprng (1996 kB).

And, provided that cupsys stabilizes enough, an unpacked size < 1.5MB (no
docs) would make it a very good candidate for a user-friendly, standard
printing system for Debian (as long as we package the KPP [see
http://cups.sourceforge.net] GUI front-end as well, that is).

As it stands, I think either promoting lprng to standard or keeping the
status-quo (lpr) are better choices for the time being (Woody).

> I conclude that cupsys-doc should probably be split off, and that a

This is a very good idea.  However, CUPS has been infected by the "see ma,
i'm a webserver as well" plague that is so common these days. Part of that
cannot be avoided, as IPP is layered over http. But cupsys also serves a lot
of help docs through its http layer, which might need some automatic
disabling or something like that when the -doc package isn't installed.

(AND that file serving is something I'd disable immediately if at all
possible, it's just not worth the danger IMHO. Same goes for PULL IPP
printing and any other stuff like that... but THAT is a really huge IMHO)

> separate cupsys-ps package that only people without PS-aware printers
> needed would be a win (perhaps this could also somehow share with
> GhostScript).

If one manages to get a pstoraster which runs GS instead of embebbeding it
(somehow keeping whatever enhancements CUPS made to the code, of course. The
idea is to dump the original pstoraster without lowering CUPS quality), that
alone would be enough to reduce the package size nicely. It shouldn't be
impossible, as CUPS 1.1 builds nicely even after a rm -rf pstoraster and
slight makefile edit :^P

> How lprng or cupsys compare on technical merit should be our main
> concern here.

I'm worried about cupsys' security. It has too much "nifty network
awareness" (i.e.: browsing, serving files(!) and running cgi scripts(!!))
for my tastes, Personally, I'll not trust it in a hostile network until I
have a LOT of time to look at it closer.

Other stuff the DEBIAN packaging of cupsys and friends would need before
going standard (IMHO, obviously): 

- To try to take advantage of magicfilter... or incorporate all that
  conversion support that magicfilter already has (at the very least DVI,
  compressed data and *roff). If CUPS has a fallback system for conversions,
  a wrapper script could be written I guess...

- To integrate CUPS with the distribution's font system (it really should
  share fonts AND font configuration with the gs-* packages) if that isn't
  done yet.  I know I would be VERY ticked off if I found out that my
  postscript stuff wasn't printing correctly because cupsys' embebedded
  postscript rasterizer was not even trying to use the postscript fonts
  installed in the system. I assume others might not like it either :-)

- Package all that nifty ammount of printer PPDs at cups.sourceforge.net if
  their license allows it. Otherwise, consider packaging a installer and add
  URLs to cupsys' README.Debian

- Package the GS PPD and related utils if the internal rasterizer can't be
  made to run GS to begin with. Without it, cupsys simply isn't useful for
  way too many people.

- Package the web-based administration separately (requiring the -docs
  package) if that proves necessary for system stability or reduces size in
  a meaningful way (better than 500kb savings IMHO).
  "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: pgp_QrJZMRrQB.pgp
Description: PGP signature

Reply to: