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@SuSE.de 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@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org