[Printing-architecture] FHS extension and CUPS

[Printing-architecture] FHS extension and CUPS

[Till Kamppeter]

Hi,

I have posted a feature request for CUPS being adapted to the new FHS 
extension 
(http://lists.freestandards.org/pipermail/printing-architecture/2006/001512.html) 
for printing:

http://www.cups.org/str.php?L2202

Mike has answered that he will implement this in CUPS 1.3.

The problems are

- Of CUPS 1.3 there is not even an alpha version, will it go final
   before the LSB 3.2 deadline?

- Novell and Red Hat want to put out an update to fulfill the FHS
   extensions. Is it not perhaps a too high impact for an enterprise
   distro to replace CUPS 1.2 (x >> 0) by CUPS 1.3, especially 1.3.0?

Or should we better recommend to the distros to simply do

ln -s /usr/share/ppd /usr/share/cups/model/usrshareppd
ln -s /opt/share/ppd /usr/share/cups/model/optshareppd
ln -s /usr/local/share/ppd /usr/share/cups/model/usrlocalshareppd

in their CUPS package for now? This makes CUPS searching for the PPDs in 
the right places.

    Till

Re: [Printing-architecture] FHS extension and CUPS

[Ian Murdock]

I'm appending a conversation I had with Tim Waugh of Red Hat about this
(posted with his permission). In short, unless it's a very trivial change
to make the current RHEL 5, SLE 10, etc. compliant with the printer driver
standard, it is not reasonable to expect this to be in LSB 3.2 (it was
my understanding that it would be trivial, as you'll read in the included
exchange). It should go without saying that it's not reasonable
to expect them to uplift to something that hasn't even been released yet.

In short, the only way this will make it into LSB 3.2 is if it's trivial
to implement, i.e., a change to the CUPS configuration or the creation of
symlinks. If it takes more than that, this will have to wait for LSB 4.0.

-ian


Forwarded Conversation
Subject: Location of printer drivers
------------------------

 From: Tim Waugh <twaugh@redhat.com>
To: Ian Murdock <imurdock@imurdock.com>
Date: Mon, Jan 15, 2007 at 11:25 AM
Attachments: signature.asc

Hi Ian,

I just read through the proposed FHS extension, and it doesn't look
workable to me:

        b. The contents of the driver directories are entirely
        determined by the supplier.  The path to a driver is found
        by using an absolute path in the ppd file.
...
5. Precedence Rules
...
    Drivers
      Admin :               /usr/local/lib(64)/printdriver Highest
      Third Party Vendor :  /opt/<supplier>
      Distro :              /usr/lib(64)/printdriver       Lowest

How can there be precedence rules when the absolute paths are used in
the PPD files?  Or do you intend for CUPS to re-write them in memory and
implement the precedence rules itself? (If so: UGH!)

Tim.
*/

--------
 From: Ian Murdock <imurdock@imurdock.com>
To: Tim Waugh <twaugh@redhat.com>
Date: Mon, Jan 15, 2007 at 11:35 AM

Hi Tim,

Hmm. Good question. I'll pass this along to the folks who wrote tihs.

Do you have suggestions on what the standard should say? I'm
much less concerned with what the behavior is than there be
some consistent behavior that we can rely on across distros.

Thanks,

-ian

--------
 From: Tim Waugh <twaugh@redhat.com>
To: Ian Murdock <imurdock@imurdock.com>
Date: Mon, Jan 15, 2007 at 11:46 AM
Attachments: signature.asc

On Mon, 2007-01-15 at 11:35 -0500, Ian Murdock wrote:
> Do you have suggestions on what the standard should say? I'm
> much less concerned with what the behavior is than there be
> some consistent behavior that we can rely on across distros.

I would suggest that there is no mechanism for magically 'over-riding'
already-installed drivers at all, i.e. no precedence rules at all for
drivers.

Tim.
*/

--------
 From: Ian Murdock <imurdock@imurdock.com>
To: Tim Waugh <twaugh@redhat.com>
Date: Tue, Jan 16, 2007 at 10:52 AM

Ok, I've passed that along too.

Assuming we can come up with something that's workable, is this something
that could be a candidate for RHEL 5 Update 1? That's the key issue for me,
because unless it is, it's not a candidate for LSB 3.2, and without
it, we'll have difficulty moving forward on some
of our other printing projects (the shared driver repository, etc.).

Thanks,

-ian

--------
 From: Tim Waugh <twaugh@redhat.com>
To: Ian Murdock <imurdock@imurdock.com>
Date: Wed, Jan 17, 2007 at 10:18 AM
Attachments: signature.asc

On Tue, 2007-01-16 at 10:52 -0500, Ian Murdock wrote:
> Assuming we can come up with something that's workable, is this something
> that could be a candidate for RHEL 5 Update 1?

Extremely unlikely.  The spec isn't workable *now*, and changes like
that can't just get thrown into Red Hat Enterprise Linux.  It's not even
in Fedora yet.

Let's make sure everyone agrees on the spec, and how to implement it,
and put the implementations through community testing first.

Tim.
*/

--------
 From: Ian Murdock <imurdock@imurdock.com>
To: Tim Waugh <twaugh@redhat.com>
Date: Wed, Jan 17, 2007 at 10:35 AM

Right, but we're talking about an extremely minor change here, ostensibly
just agreeing on a set of paths, with big upside if we can manage to do
that. And it's entirely additive--you don't have to change your current
paths, just append the common path to the configuration file. Or am I
missing something? Granted, I'm no doubt oversimplifying, but I
don't think there's huge risk here, whereas there could be big reward.

If it's more complicated than that, then I do agree we're pushing a
bit hard here. I'm hoping I'm right though. I explicitly asked
this be done in such a way that it would be as
minor a change as possible precisely so we could move quickly.

-ian

--------
 From: Tim Waugh <twaugh@redhat.com>
To: Ian Murdock <imurdock@imurdock.com>
Date: Wed, Jan 17, 2007 at 10:40 AM
Attachments: signature.asc

On Wed, 2007-01-17 at 10:35 -0500, Ian Murdock wrote:
> Right, but we're talking about an extremely minor change here,

No, it's not.  It means changing the method by which the "appropriate"
PPD for a printer is decided.  That means changing (a) CUPS and (b)
system-config-printer, both in non-trivial ways.

Otherwise what's the PPD search path for?

Tim.
*/

--------
 From: Ian Murdock <imurdock@imurdock.com>
To: Tim Waugh <twaugh@redhat.com>
Date: Wed, Jan 17, 2007 at 10:49 AM

Ok. I had assumed the driver search path worked like other paths, and
that the main problem was getting CUPS etc. to see that a new driver had
been installed. In other words, different distros put the drivers in
different locations in the file system, so the main job that needed to be
done was to settle on a common location, and from there, it was a
matter of configuring CUPS to look in that common location.
Again, I'm no expert here, so I was probably just oversimplifying.

Thanks for the feedback--I'll pass it along to the OpenPrinting group
and will keep you posted on what they come up with.

P.S. - Do you mind if I forward this exchange to a public mailing list,
or would you rather I summarize?

-ian

--------
 From: Tim Waugh <twaugh@redhat.com>
To: Ian Murdock <imurdock@imurdock.com>
Date: Wed, Jan 17, 2007 at 10:54 AM
Attachments: signature.asc

On Wed, 2007-01-17 at 10:49 -0500, Ian Murdock wrote:
> Ok. I had assumed the driver search path worked like other paths, and
> that the main problem was getting CUPS etc. to see that a new driver had
> been installed.

As I read it, the idea is to allow the sysadmin to "over-ride" the
system-provided PPDs, which is a different prospect and needs special
handling in all the PPD-finding tools.

>  In other words, different distros put the drivers in
> different locations in the file system, so the main job that needed to be
> done was to settle on a common location, and from there, it was a
> matter of configuring CUPS to look in that common location.
> Again, I'm no expert here, so I was probably just oversimplifying.

That part -- the common location part -- makes sense.  But even
something as simple as tweaking CUPS to look in a different directory
from /usr/share/cups/model is not entirely trivial.  It would be ideal
if the only change needed is to add a symbolic link
in /usr/share/cups/model to point to the common location, which is
provided by "the system" as a physical directory.

> P.S. - Do you mind if I forward this exchange to a public mailing list,
> or would you rather I summarize?

Forwarding the exchange is fine.

Thanks,
Tim.
*/

--------

-- 
Ian Murdock
317-863-2590
http://ianmurdock.com/

"Don't look back--something might be gaining on you." --Satchel Paige

Re: [Printing-architecture] FHS extension and CUPS

[Till Kamppeter]

Leaving out the precedence rules one needs really only symlinks in 
/usr/share/cups/model to make CUPS searching the new directories.

The precedence rules should be implemented by the order how the PPD 
directories are searched for (as the drivers itself are tied to their 
PPD via the absolute path in the PPD). The search should be started in 
/usr/local/share/ppd/, followed by /opt/share/ppd, and after that 
/usr/share/ppd. Probaly one can reach this by appropriate naming of the 
symlinks. I will try that out later. If this works, we can introduce the 
new directories by only adding the symlinks which should be low-impact 
enough for the enterprise distros.

Instalation of new drivers will not replace drivers of existing queues 
(if the original driver is not overwritten by the new one). The queue 
has always be modified manually (but the FHS extension does not talk 
about auto-update of existing queues).

    Till



Ian Murdock wrote:
> I'm appending a conversation I had with Tim Waugh of Red Hat about this
> (posted with his permission). In short, unless it's a very trivial change
> to make the current RHEL 5, SLE 10, etc. compliant with the printer driver
> standard, it is not reasonable to expect this to be in LSB 3.2 (it was
> my understanding that it would be trivial, as you'll read in the included
> exchange). It should go without saying that it's not reasonable
> to expect them to uplift to something that hasn't even been released yet.
> 
> In short, the only way this will make it into LSB 3.2 is if it's trivial
> to implement, i.e., a change to the CUPS configuration or the creation of
> symlinks. If it takes more than that, this will have to wait for LSB 4.0.
> 
> -ian
> 
> 
> Forwarded Conversation
> Subject: Location of printer drivers
> ------------------------
> 
> From: Tim Waugh <twaugh@redhat.com>
> To: Ian Murdock <imurdock@imurdock.com>
> Date: Mon, Jan 15, 2007 at 11:25 AM
> Attachments: signature.asc
> 
> Hi Ian,
> 
> I just read through the proposed FHS extension, and it doesn't look
> workable to me:
> 
>        b. The contents of the driver directories are entirely
>        determined by the supplier.  The path to a driver is found
>        by using an absolute path in the ppd file.
> ...
> 5. Precedence Rules
> ...
>    Drivers
>      Admin :               /usr/local/lib(64)/printdriver Highest
>      Third Party Vendor :  /opt/<supplier>
>      Distro :              /usr/lib(64)/printdriver       Lowest
> 
> How can there be precedence rules when the absolute paths are used in
> the PPD files?  Or do you intend for CUPS to re-write them in memory and
> implement the precedence rules itself? (If so: UGH!)
> 
> Tim.
> */
> 
> --------
> From: Ian Murdock <imurdock@imurdock.com>
> To: Tim Waugh <twaugh@redhat.com>
> Date: Mon, Jan 15, 2007 at 11:35 AM
> 
> Hi Tim,
> 
> Hmm. Good question. I'll pass this along to the folks who wrote tihs.
> 
> Do you have suggestions on what the standard should say? I'm
> much less concerned with what the behavior is than there be
> some consistent behavior that we can rely on across distros.
> 
> Thanks,
> 
> -ian
> 
> --------
> From: Tim Waugh <twaugh@redhat.com>
> To: Ian Murdock <imurdock@imurdock.com>
> Date: Mon, Jan 15, 2007 at 11:46 AM
> Attachments: signature.asc
> 
> On Mon, 2007-01-15 at 11:35 -0500, Ian Murdock wrote:
>> Do you have suggestions on what the standard should say? I'm
>> much less concerned with what the behavior is than there be
>> some consistent behavior that we can rely on across distros.
> 
> I would suggest that there is no mechanism for magically 'over-riding'
> already-installed drivers at all, i.e. no precedence rules at all for
> drivers.
> 
> Tim.
> */
> 
> --------
> From: Ian Murdock <imurdock@imurdock.com>
> To: Tim Waugh <twaugh@redhat.com>
> Date: Tue, Jan 16, 2007 at 10:52 AM
> 
> Ok, I've passed that along too.
> 
> Assuming we can come up with something that's workable, is this something
> that could be a candidate for RHEL 5 Update 1? That's the key issue for me,
> because unless it is, it's not a candidate for LSB 3.2, and without
> it, we'll have difficulty moving forward on some
> of our other printing projects (the shared driver repository, etc.).
> 
> Thanks,
> 
> -ian
> 
> --------
> From: Tim Waugh <twaugh@redhat.com>
> To: Ian Murdock <imurdock@imurdock.com>
> Date: Wed, Jan 17, 2007 at 10:18 AM
> Attachments: signature.asc
> 
> On Tue, 2007-01-16 at 10:52 -0500, Ian Murdock wrote:
>> Assuming we can come up with something that's workable, is this something
>> that could be a candidate for RHEL 5 Update 1?
> 
> Extremely unlikely.  The spec isn't workable *now*, and changes like
> that can't just get thrown into Red Hat Enterprise Linux.  It's not even
> in Fedora yet.
> 
> Let's make sure everyone agrees on the spec, and how to implement it,
> and put the implementations through community testing first.
> 
> Tim.
> */
> 
> --------
> From: Ian Murdock <imurdock@imurdock.com>
> To: Tim Waugh <twaugh@redhat.com>
> Date: Wed, Jan 17, 2007 at 10:35 AM
> 
> Right, but we're talking about an extremely minor change here, ostensibly
> just agreeing on a set of paths, with big upside if we can manage to do
> that. And it's entirely additive--you don't have to change your current
> paths, just append the common path to the configuration file. Or am I
> missing something? Granted, I'm no doubt oversimplifying, but I
> don't think there's huge risk here, whereas there could be big reward.
> 
> If it's more complicated than that, then I do agree we're pushing a
> bit hard here. I'm hoping I'm right though. I explicitly asked
> this be done in such a way that it would be as
> minor a change as possible precisely so we could move quickly.
> 
> -ian
> 
> --------
> From: Tim Waugh <twaugh@redhat.com>
> To: Ian Murdock <imurdock@imurdock.com>
> Date: Wed, Jan 17, 2007 at 10:40 AM
> Attachments: signature.asc
> 
> On Wed, 2007-01-17 at 10:35 -0500, Ian Murdock wrote:
>> Right, but we're talking about an extremely minor change here,
> 
> No, it's not.  It means changing the method by which the "appropriate"
> PPD for a printer is decided.  That means changing (a) CUPS and (b)
> system-config-printer, both in non-trivial ways.
> 
> Otherwise what's the PPD search path for?
> 
> Tim.
> */
> 
> --------
> From: Ian Murdock <imurdock@imurdock.com>
> To: Tim Waugh <twaugh@redhat.com>
> Date: Wed, Jan 17, 2007 at 10:49 AM
> 
> Ok. I had assumed the driver search path worked like other paths, and
> that the main problem was getting CUPS etc. to see that a new driver had
> been installed. In other words, different distros put the drivers in
> different locations in the file system, so the main job that needed to be
> done was to settle on a common location, and from there, it was a
> matter of configuring CUPS to look in that common location.
> Again, I'm no expert here, so I was probably just oversimplifying.
> 
> Thanks for the feedback--I'll pass it along to the OpenPrinting group
> and will keep you posted on what they come up with.
> 
> P.S. - Do you mind if I forward this exchange to a public mailing list,
> or would you rather I summarize?
> 
> -ian
> 
> --------
> From: Tim Waugh <twaugh@redhat.com>
> To: Ian Murdock <imurdock@imurdock.com>
> Date: Wed, Jan 17, 2007 at 10:54 AM
> Attachments: signature.asc
> 
> On Wed, 2007-01-17 at 10:49 -0500, Ian Murdock wrote:
>> Ok. I had assumed the driver search path worked like other paths, and
>> that the main problem was getting CUPS etc. to see that a new driver had
>> been installed.
> 
> As I read it, the idea is to allow the sysadmin to "over-ride" the
> system-provided PPDs, which is a different prospect and needs special
> handling in all the PPD-finding tools.
> 
>>  In other words, different distros put the drivers in
>> different locations in the file system, so the main job that needed to be
>> done was to settle on a common location, and from there, it was a
>> matter of configuring CUPS to look in that common location.
>> Again, I'm no expert here, so I was probably just oversimplifying.
> 
> That part -- the common location part -- makes sense.  But even
> something as simple as tweaking CUPS to look in a different directory
> from /usr/share/cups/model is not entirely trivial.  It would be ideal
> if the only change needed is to add a symbolic link
> in /usr/share/cups/model to point to the common location, which is
> provided by "the system" as a physical directory.
> 
>> P.S. - Do you mind if I forward this exchange to a public mailing list,
>> or would you rather I summarize?
> 
> Forwarding the exchange is fine.
> 
> Thanks,
> Tim.
> */
> 
> --------
> 

Re: [Printing-architecture] FHS extension and CUPS

[Michael Sweet]

Ian Murdock wrote:
> I'm appending a conversation I had with Tim Waugh of Red Hat about this
> (posted with his permission). In short, unless it's a very trivial change
> to make the current RHEL 5, SLE 10, etc. compliant with the printer driver
> standard, it is not reasonable to expect this to be in LSB 3.2 (it was
> my understanding that it would be trivial, as you'll read in the included
> exchange). It should go without saying that it's not reasonable
> to expect them to uplift to something that hasn't even been released yet.
> 
> In short, the only way this will make it into LSB 3.2 is if it's trivial
> to implement, i.e., a change to the CUPS configuration or the creation of
> symlinks. If it takes more than that, this will have to wait for LSB 4.0.
 > ...

OK, for PPD "paths", I would recommend simply making symlinks in
/usr/share/cups/model so that CUPS can find the PPD files.  That
works with current CUPS and all the way back to the 1.0 release.

Another method would be to provide a separate CUPS driver interface
program that scans the FHS PPD directories, but IMHO that is
overkill and completely unnecessary.

FWIW, I *do not* support the notion of a "relative" PPD name that is
then looked up in a specific order of directories.  That is, adding
a printer using a PPD file called "foo.ppd" should always use the
same PPD file - otherwise you can run into a lot of issues ranging
from simple confusion to security problems.  The separate system/
local/vendor directories do not prevent a user/administrator from
choosing a locally-modified PPD, and part of those modifications can
be to the NickName so that the local users realize that the modified
PPD is the one they want, e.g. "HP LaserJet 4000 - Use This One".

Similarly, LSB printer drivers should specify their install
path in the cupsFilter attribute unless they are using a
standard CUPS-supplied driver, currently rastertoescpx,
rastertoepson, rastertohp, rastertolabel, or rastertopclx.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com

Re: [Printing-architecture] FHS extension and CUPS

[Till Kamppeter]

I have investigated somewhat more and my recommendations are to do the 
following in the distros:

1. Create directories

mkdir -p /usr/share/ppd (not needed in Ubuntu)
mkdir -p /opt/share/ppd
mkdir -p /usr/local/share/ppd

mkdir -p /usr/lib/printdriver
mkdir -p /opt/lib/printdriver
mkdir -p /usr/local/lib/printdriver

2, Set symlinks for CUPS to find the PPDs:

Ubuntu:

ln -s /usr/local/share/ppd /usr/share/ppd/1-local-admin
ln -s /opt/share/ppd /usr/share/ppd/2-third-party

Other distributions:

ln -s /usr/local/share/ppd /usr/share/cups/model/1-local-admin
ln -s /opt/share/ppd /usr/share/cups/model/2-third-party
ln -s /usr/share/ppd /usr/share/cups/model/3-distribution

These serves for CUPS finding the PPDs in the standardized directories. 
The numbers in the link names make the PPDs being listed in the right 
order, so that when the printer setup tool marks te first suitable PPD 
by default, the precedence rules are fulfilled.

The PPDs must contain absolute paths to the driver binaries. so that 
they get found.

    Till


Michael Sweet wrote:
> Ian Murdock wrote:
>> I'm appending a conversation I had with Tim Waugh of Red Hat about this
>> (posted with his permission). In short, unless it's a very trivial change
>> to make the current RHEL 5, SLE 10, etc. compliant with the printer 
>> driver
>> standard, it is not reasonable to expect this to be in LSB 3.2 (it was
>> my understanding that it would be trivial, as you'll read in the included
>> exchange). It should go without saying that it's not reasonable
>> to expect them to uplift to something that hasn't even been released yet.
>>
>> In short, the only way this will make it into LSB 3.2 is if it's trivial
>> to implement, i.e., a change to the CUPS configuration or the creation of
>> symlinks. If it takes more than that, this will have to wait for LSB 4.0.
>  > ...
> 
> OK, for PPD "paths", I would recommend simply making symlinks in
> /usr/share/cups/model so that CUPS can find the PPD files.  That
> works with current CUPS and all the way back to the 1.0 release.
> 
> Another method would be to provide a separate CUPS driver interface
> program that scans the FHS PPD directories, but IMHO that is
> overkill and completely unnecessary.
> 
> FWIW, I *do not* support the notion of a "relative" PPD name that is
> then looked up in a specific order of directories.  That is, adding
> a printer using a PPD file called "foo.ppd" should always use the
> same PPD file - otherwise you can run into a lot of issues ranging
> from simple confusion to security problems.  The separate system/
> local/vendor directories do not prevent a user/administrator from
> choosing a locally-modified PPD, and part of those modifications can
> be to the NickName so that the local users realize that the modified
> PPD is the one they want, e.g. "HP LaserJet 4000 - Use This One".
> 
> Similarly, LSB printer drivers should specify their install
> path in the cupsFilter attribute unless they are using a
> standard CUPS-supplied driver, currently rastertoescpx,
> rastertoepson, rastertohp, rastertolabel, or rastertopclx.
> 

Re: [Printing-architecture] FHS extension and CUPS

[Michael Sweet]

Till Kamppeter wrote:
> ...
> - Of CUPS 1.3 there is not even an alpha version, will it go final
>    before the LSB 3.2 deadline?

Probably, but the more important issue is whether CUPS 1.3 will
be adopted by the distros before the LSB 3.2 deadline...

Right now I'm tied up with other (paying) tasks, but I'm hoping
to get 1.2.8 and 1.3b1 released in 3-4 weeks.

> - Novell and Red Hat want to put out an update to fulfill the FHS
>    extensions. Is it not perhaps a too high impact for an enterprise
>    distro to replace CUPS 1.2 (x >> 0) by CUPS 1.3, especially 1.3.0?

Given the scope of this "extension", I don't think it is necessary
(or fair) to force distros to ship CUPS 1.3 for LSB 3.2 compliance.

> Or should we better recommend to the distros to simply do
> 
> ln -s /usr/share/ppd /usr/share/cups/model/usrshareppd
> ln -s /opt/share/ppd /usr/share/cups/model/optshareppd
> ln -s /usr/local/share/ppd /usr/share/cups/model/usrlocalshareppd
> 
> in their CUPS package for now? This makes CUPS searching for the PPDs in 
> the right places.

The simplest solution is often the best solution.  While we *will*
add support for configurable PPD paths to cups-driverd, using
symlinks now is the best way to go for CUPS 1.2.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com