Mailinglist Archive: opensuse-factory (393 mails)

< Previous Next >
Re: [opensuse-factory] Re: Meeting minutes dist meeting 2007-03-23
  • From: Klaus Singvogel <kssingvo@xxxxxxx>
  • Date: Wed, 28 Mar 2007 18:17:08 +0200
  • Message-id: <20070328161708.GA22975@xxxxxxx>
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@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 >