Mailinglist Archive: opensuse-factory (393 mails)

< Previous Next >
[opensuse-factory] Re: Meeting minutes dist meeting 2007-03-23
  • From: Klaus Singvogel <kssingvo@xxxxxxx>
  • Date: Mon, 26 Mar 2007 16:40:10 +0200
  • Message-id: <20070326144010.GA28292@xxxxxxx>
JP Rosevear wrote:
> On Mon, 2007-03-26 at 14:41 +0200, Klaus Singvogel wrote:
> I noted the discussion had stalled on factory, we became way bogged down
> on the issue of root vs non-root, questioning the fundamental use case
> after it was agreed on in previous dist meetings rather than focusing on
> solutions for the cases, so Chris Rivera has been doing more research
> that should be reported this week.

Thanks for the update.

> > Why we should _not_ use Hal backend:
[...]
> 
> I said in the dist meeting I was not convinced we should use the hal
> backend, I was noting RedHat uses it and has no intention of stopping.
> We may still need to solve the hal uri -> cups usb URI mapping problem
> though if we want to trigger intelligent behavior when a usb printer is
> plugged in.

hal provides for a device the same information, which usb backend
of CUPS uses: vendor, model, serial number.

A few execptions are done for some vendors: so "Hewlett-Packard"
(regardless of lower-/uppercase writing) is always mapped to "HP".
This was done to be compatible with PPD and ICC spec naming.

It should be easy with these information to do a mapping between
hal device_id and the cups device_uri naming. A simple scan should
be enough. :-)

> > We should not use the automatic setup solution from Fedora:
> > - The origin of the database seems not to be public. We cannot react
> >   if we want to handle all of our supported printers just before a
> >   product realase. We are always one release cycle behind
> >   RedHat/Fedora if we want to use their solution. No improvements
> >   at our side.
> 
> I noted it could be a starting point, nothing more.  How do we generate
> our database?  No one in the previous dist meetings indicating we had a
> good mapping of printers to print drivers and noted that previous
> efforts to collect this data had failed.

YaST already uses one. :-)

To summarize it:

CUPS collection of PPD files (/usr/share/cups/model/*) contains the
information for which printer drivers (please note the plural form)
can be used (and how) for a single, specific printer. One PPD file for
a specific printer contain the word "(recommended)" in the field
"*NickName".

But there exists a specific subdirectory below /usr/share/cups/model :
/usr/share/cups/model/manufacturer-PPDs. If there is a printer listed
in one of these sub-subdirectories there, then this printer driver
should be prefered, otherwise the one from above: with "(recommended)"
in the field "*NickName".

Note that /usr/share/cups/model consists of subdirectories, and
/usr/share/cups/model/manufacturer-PPDs is one of them, but needs to
be handled special.

If you're unfamiliar with PPD files, or need just a source reference
about them, use:
  http://partners.adobe.com/public/developer/en/ps/5003.PPD_Spec_v4.3.pdf

> 
> > - The automatic setup didn't show any further development at
> >   Fedora/RedHat since quiet some time (it's outdated!). This was the
> >   main reason, why even Ubuntu/Debian went away and uses now
> >   printerdrake.
> > - We already have a in-house solution, named YaST!!! Why cant we use
> >   that? YaST already does automatic printer installation, when doing a
> >   new system installation. It should be no major effort, to enhance
> >   YaST in such a way that we get an command-line interface to do this.
> 
> Fine with me to examine, but no one had proposed this at all, as noted
> above the discussion got completely side tracked on the root/non-root
> issue.

Ok.

But I still had the feeling that those steps can be developed
independently from each others. Please forgive me for my ongoing
discussing, even there are situation where someone might see a break
for investigation.

I'm having the feeling that we could still discuss the other parts,
as they can be developed independently.

There are more or less obvious interfaces for me in development: the
call-backs of the hal system, the mapping of "hal device ids" <->
"cups usb device_uris", the selection of a printer driver and
installation process (or the enhancement of YaST). But also the remove
of a printer when unplugged happens, and the book-keeping for a change
of state when a reboot happens.

Please keep in mind, that installation of printers in the CUPS system
is boot persistent, but this contradicts the plug/unplug philosophie
and the volatile installation of hal devices. So an additional
mechanism needs to be developed here.

Regards,
        Klaus.
-- 
Klaus Singvogel
SUSE LINUX Products GmbH
Maxfeldstr. 5                     E-Mail: Klaus.Singvogel@xxxxxxx
90409 Nuernberg                   Phone: +49 (0) 911 740530
Germany                           GnuPG-Key-ID: 1024R/5068792D  1994-06-27

SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >