Chris Rivera wrote:
On Mon, 2007-03-26 at 16:40 +0200, Klaus Singvogel wrote:
After further investigation I don't think using the HAL backend buys us anything if we need to keep the usb backend around. It just creates more work mapping between the two uri schemes to resolve ambiguities without giving us any real benefit other than being cleaner. In an ideal world HAL would be used to detect hardware, but we can still leverage HAL callouts without using the HAL uri scheme.
Yes, I came to the same result after doing these investigations. Thanks.
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. :-)
Is /var/lib/YaST2/ppd_db.ycp the one you're referring to? How is this generated? Where do you get the mapping information from?
Sorry, but I'm not the author of the printer part of YaST2. It's developed in Czech, and I think the current developers name is Michal Zugec. I noticed this possibility of YaST during last installation, and thought it is worth telling about here.
Also, Fedora uses Foomatic, which is in no way private. Is there any reason why we don't ship and use Foomatic?
Sorry to say, but we ship Foomatic too. But it's possible to ship Foomatic in different ways: as an uncompiled database or with compiled PPDs. In the past (cups-1.1.x) it was necessary to ship it in compiled form, but now (cups-1.2.x) distributions have the choice as both ways are supported. I still kept the compiled form, because it seems to be less error prone, it's easier to remove unsupported printers in the database (e.g. due to license issues), and to find those which are supported, as they contain a more mnemonic file name in the system (finding them via beagle or findutils-locate).
There are tools other than Yast that need a printer to ppd/driver mapping. The parsing and fuzzy mapping of ppd files on the system is painful. It would be nice to have one solution used by all of our tools.
I think we shouldn't dig to deep into YaST here, and let YaST do it's magic as it is. An additional commandline interface with a valid cups device-uri should be enough. Letting YaST doing all the rest of the installation magic without spending to much effort in rewriting the code. :-) I'm thinking of this kind of interface: yast install_printer usb://Brother/HL-5150D%20series
- 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.
Printerdrake also uses automatic queue setup. See https://wiki.ubuntu.com/PrinterDrake.
Aah, yes. Thanks.
- 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.
I'd be happy to chat with you about the requirements for this piece of the puzzle and how we can go about doing this.
I'm not quiet sure now, if I'm the right person. I'm not very familiar with YaST, it's Michal Zugec. I only know a lot about CUPS, Foomatic, and the gory internals of those. And I'll be happy if I can share those information with you. My goal is to get the best perfect fitting solution for our distribution whatever we can get. If you still think that I'm the right person, feel free to contact by any kind of media you want to use: telefon, groupwise messanger, irc, etc.
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.
We might not even need a mapping for the uris. We can simply use the callout as a "a new printer was added" event. We can then use the list of printers detected by the backends and compare them to the list cups knows about to figure out which printers need to be setup. Just a thought.
I agree with you. But I was talking about a different situation: a printer gets removed from the system while there was a shutdown. I had the feeling that we don't get any HAL callouts of "a printer is removed" when the system comes up again. But the information of the installed printer is still stored in the CUPS system. How is this printer removed in CUPS then, if we don't get the callout? Another advantage when doing this kind of book-keeping can be: The configuration of the removed printer can be stored in a different place. Next time when the same printer gets replugged, the stored information (e.g. resolution, default page size, etc) can be used, and there is no data loss in the configuration. But... it should be clear that YaST shouldn't be used in such a case for printer installation. Just a thought about future enhancements. 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