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? Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
