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

Re: "cupsys" renamed to "cups", please adjust your (build-)depends

Hi Bernhard,

Bernhard R. Link [2008-06-12 18:23 +0200]:
> How about using this transition to move some binaries between package
> boundaries? Especially having some programs with generic names in -client and
> some in -bsd seem to be a problem for some users (like #405827).

I do not agree to this bug report. CUPS upstream's native tools have
sysv names, so they should be in cups-client, and not a package which
says "please do not install me". With those you can access all the
features of cups (especially with lpadmin and lpinfo). Also, it
already renames the very generic 'enable' and 'disable' commands to
'cupsenable' and 'cupsdisable'. But we cannot really do that for all
the other frontend programs (lp, etc.), since their names have a long
history and are just expected to be named like this. Renaming them now
would break a lot.

You can install a cups server without the client programs, and thus
only use IPP for printing (as done by GNOME/KDE/gtkprint, etc.).

So isn't the real problem that lprng isn't split into a client and
server side package? If it was, you could mix them by installing
cups and lprng-client, or the other way around (no idea whether this
actually makes sense and would work, and whether the wire protocols
are compatible).

> I do not think having lp and lpr in different packages can cause any
> good (and the same for lprm and cancel and so on).

The cups-bsd package should really stay split, too, IMHO. They are a
compatibility layer, and you do not need to have them installed in
order to use cups for printing on the client side. Also, from your
POV, merging -bsd into -client would only aggravate the problem?



Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Attachment: signature.asc
Description: Digital signature

Reply to: