On Mon, 2007-03-26 at 14:41 +0200, Klaus Singvogel wrote:
Andreas Jaeger wrote: [...]
* Status on print configuration
- Discussion on opensuse-factory has been started. - Cups 1.2 has policies - and there's also discussion about role based YaST. We should avoid too many different solutions. - Red Hat seems to use hal backend. - Looking at Fedora solutions, they have some database for automatic setup. - not sure what can be done in time for 10.3
I'm wondering how this _result_ came up.
The discussion on opensuse-factory seemed to have stopped, whereas in the dist meeting were now some results presented, which seem not to honor some important facts, and seem not to be common positions.
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.
So I cannot agree with the later listed results, i.e. the RedHat/Fedora related ones.
Why we should _not_ use Hal backend: - We cannot use hal backend, if we have need to support printing ability of multifunction printers (scanner/printer/fax). The lock of the usb device when supporting the scanning functionality is the main reason. - To have a full support of printers, we need to support vendor specific backends (!= hal backend), like those from HP or Epson. - The hal backend lacks still of implementation of new features of the cups-1.2.x system. The upstream maintainer (RedHat/Fedora) doesn't show any activity regarding this since release of cups-1.2x (9 months). ==> outdated. - It's not necessary to use the hal backend just to have the hal functionality of plugin/remove of printers use. Writing a hal policy file (.fdi file) with call of an Novell/SuSE specific tool should be enough/better.
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.
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.
- 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.
-JP
--
JP Rosevear