Re: ITP: task-cups-printing
Henrique M Holschuh <hmh+debianml@rcm.org.br> wrote:
>Mariusz.Przygodzki@WAW1.siemens.pl wrote:
>> Thanks.I has just reviewed this discussion and I have headache.
>> I have some proposal and please don't blame me
>> if somebody is not happy from it.
>> What's wrong in following proposal (this is only theoretical game):
>>
>> 1. We have standard package task-printing.
>> 2. task-printing depends on
>> lpr | task-lprng-printing | task-cups-printing | task-...
>> and above packages are optional (except of lpr)
>> and conflicts between themselves.
>
> I'd prefer if the GUI CLIENT frontend packages were added as
> Suggests: to the client cupsys package, any eventual GUI server
> frontends added as Suggests: to the server cupsys package, and no
> task-cups-printing package tot ever see the light of the day.
>
> The less task-* packages we have, the better. Besides, that's what
> Suggests: (and Recommends:, I suppose) are there for.
>
> Now, task-print-server (or whatever the task package for printing
> is) might depend on lpr | lprng | cupsys (not real package
> names). That's something else entirely. I personally don't think
> CUPS is stable enough yet to be pushed as a standard printing
> package for Debian (I may not have worked in any CUPS stuff for a
> while, but I do read the CUPS mailing list), but that's not for me
> to decide, AND only my humble opinion.
Oh, it's a humble opinion shared by many. The world is ripe for a new
Unix printing system, but among the current 6-odd choices no one is
perfect. No matter; Debian includes them all ;)
In any case, as I said in an earlier thread, Jeff (the CUPS
maintainer) and I discussed a variation on this theme in August.
Here's what we boiled it down to; as you'll see it doesn't really
include front-ends so much as backend and config tools, but the idea
is sound:
Jeff wrote:
> Grant wrote:
>> As for the packaging, I've got assorted ideas on how to best do
>> this. Basically, there should be a (or a choice of) config tools,
>> built atop the config library, which depends on the facility
>> "print-spooler". The print-spooler packages should all suggest
>> something like task-print-drivers, which would depend on every
>> driver known to man. The config library can handle snarfing the
>> latest, greatest actual data from my site or a suitable mirror; I'm
>> not sure that packaging it whole is the best thing, since it changes
>> constantly - maybe just a monthly or weekly snapshot?
>
> What about both? Some reasonably up-to-date version for
> anon-net-connected people or paranoids, with the option to pull a
> more current one from the outside?
>
> Something like this could be done:
>
> libprintdb(-dev) (the library)
> printdb-tools (any spooler-independent stuff, like the downloader)
> printdb-data (a local copy of some snapshot of the database)
> printdb-spooler (virtual package provided by spooler hooks)
> printdb-cupsys (hooks for CUPS)
> printdb-pdq (hooks for PDQ)
> ...
>
> Then, the library could use the downloaded database if it exists, and
> fall back on the packaged one.
In light of this current discussion, task-print-drivers is probably a
bad idea, but there are a few dozen non-Ghostscript drivers out there
now that it would be nice to have fit into the Debian way, somehow.
Perhaps they should all be suggested by any/every spooler?
--
Grant Taylor - gtaylor@picante.com - http://www.picante.com/~gtaylor/
Linux Printing Website and HOWTO: http://www.linuxprinting.org/
Reply to: