Re: [Printing-architecture] resend notes from last week

Re: [Printing-architecture] resend notes from last week

[Fujinaka, Todd]

>-----Original Message-----
>From: Till Kamppeter [mailto:till.kamppeter@gmail.com]
>
>But third-party CUPS drivers go into /usr/lib/cupss/filter and
>/usr/share/cups/model. So there is third-party software which goes into
>/usr.

Yes, this is wrong, AFAIK. CUPS can have 3rd party drivers /usr (in
specific places) as long as the distro provides them. Other people (like
printer manufacturers) are not allowed to add to /usr.

>So third-party CUPS drivers are violating the standards currently, due
>to requirements of CUPS.

Yes. Currently this is what CUPS does. Mike Sweet said he'd change
things around to allow other directories (correct me if I'm wrong).

I keep harping on the FHS because it's a requirement of LSB, and I'm
working on the LSB project. We'd like to have the printing directory
structure in LSB, but if the printing directory structure conflicts with
the FHS we'd have ambiguities. Ambiguous standard won't be much use to
anyone.

Thanks,
Todd

Re: [Printing-architecture] resend notes from last week

[Till Kamppeter]

Fujinaka, Todd wrote:
>>-----Original Message-----
>>From: Till Kamppeter [mailto:till.kamppeter@gmail.com]
>>
>>But third-party CUPS drivers go into /usr/lib/cupss/filter and
>>/usr/share/cups/model. So there is third-party software which goes into
>>/usr.
> 
> 
> Yes, this is wrong, AFAIK. CUPS can have 3rd party drivers /usr (in
> specific places) as long as the distro provides them. Other people (like
> printer manufacturers) are not allowed to add to /usr.
> 
> 
>>So third-party CUPS drivers are violating the standards currently, due
>>to requirements of CUPS.
> 
> 
> Yes. Currently this is what CUPS does. Mike Sweet said he'd change
> things around to allow other directories (correct me if I'm wrong).
> 
> I keep harping on the FHS because it's a requirement of LSB, and I'm
> working on the LSB project. We'd like to have the printing directory
> structure in LSB, but if the printing directory structure conflicts with
> the FHS we'd have ambiguities. Ambiguous standard won't be much use to
> anyone.
> 

Then I would suggest that we settle on

/usr/share/ppd/<supplier>/<manufacturer>/

dor the PPDs which make part of the distribution and

/usr/lib/printdrivers/<supplier>

for the drivers which make part of the distribution.

The third-party PPDs go into

/opt/printing/ppd/<supplier>/<manufacturer>/

and the third-party drivers into

/opt/printing/drivers/<supplier>/

Are more directories needed?

WDYT?

   Till

Re: [Printing-architecture] resend notes from last week

[Michael Sweet]

Till Kamppeter wrote:
> Fujinaka, Todd wrote:
>>> -----Original Message-----
>>> From: Till Kamppeter [mailto:till.kamppeter@gmail.com]
>>>
>>> But third-party CUPS drivers go into /usr/lib/cupss/filter and
>>> /usr/share/cups/model. So there is third-party software which goes into
>>> /usr.
>>
>> Yes, this is wrong, AFAIK. CUPS can have 3rd party drivers /usr (in
>> specific places) as long as the distro provides them. Other people (like
>> printer manufacturers) are not allowed to add to /usr.
>>
>>
>>> So third-party CUPS drivers are violating the standards currently, due
>>> to requirements of CUPS.
>>
>> Yes. Currently this is what CUPS does. Mike Sweet said he'd change
>> things around to allow other directories (correct me if I'm wrong).
>>
>> I keep harping on the FHS because it's a requirement of LSB, and I'm
>> working on the LSB project. We'd like to have the printing directory
>> structure in LSB, but if the printing directory structure conflicts with
>> the FHS we'd have ambiguities. Ambiguous standard won't be much use to
>> anyone.
>>
> 
> Then I would suggest that we settle on
> 
> /usr/share/ppd/<supplier>/<manufacturer>/
> 
> dor the PPDs which make part of the distribution and
> 
> /usr/lib/printdrivers/<supplier>
> 
> for the drivers which make part of the distribution.
> 
> The third-party PPDs go into
> 
> /opt/printing/ppd/<supplier>/<manufacturer>/
> 
> and the third-party drivers into
> 
> /opt/printing/drivers/<supplier>/
> 
> Are more directories needed?

/usr/local/share/ppd/<supplier>/<manufacturer>
/usr/local/lib/printdrivers/<supplier>

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

Re: [Printing-architecture] resend notes from last week

[Till Kamppeter]

Michael Sweet wrote:
> Till Kamppeter wrote:
> 
>> Fujinaka, Todd wrote:
>>
>>>> -----Original Message-----
>>>> From: Till Kamppeter [mailto:till.kamppeter@gmail.com]
>>>>
>>>> But third-party CUPS drivers go into /usr/lib/cupss/filter and
>>>> /usr/share/cups/model. So there is third-party software which goes into
>>>> /usr.
>>>
>>>
>>> Yes, this is wrong, AFAIK. CUPS can have 3rd party drivers /usr (in
>>> specific places) as long as the distro provides them. Other people (like
>>> printer manufacturers) are not allowed to add to /usr.
>>>
>>>
>>>> So third-party CUPS drivers are violating the standards currently, due
>>>> to requirements of CUPS.
>>>
>>>
>>> Yes. Currently this is what CUPS does. Mike Sweet said he'd change
>>> things around to allow other directories (correct me if I'm wrong).
>>>
>>> I keep harping on the FHS because it's a requirement of LSB, and I'm
>>> working on the LSB project. We'd like to have the printing directory
>>> structure in LSB, but if the printing directory structure conflicts with
>>> the FHS we'd have ambiguities. Ambiguous standard won't be much use to
>>> anyone.
>>>
>>
>> Then I would suggest that we settle on
>>
>> /usr/share/ppd/<supplier>/<manufacturer>/
>>
>> dor the PPDs which make part of the distribution and
>>
>> /usr/lib/printdrivers/<supplier>
>>
>> for the drivers which make part of the distribution.
>>
>> The third-party PPDs go into
>>
>> /opt/printing/ppd/<supplier>/<manufacturer>/
>>
>> and the third-party drivers into
>>
>> /opt/printing/drivers/<supplier>/
>>
>> Are more directories needed?
> 
> 
> /usr/local/share/ppd/<supplier>/<manufacturer>
> /usr/local/lib/printdrivers/<supplier>
> 

Is it not enough agreeing on one ofthe pairs

/usr/local/share/ppd/<supplier>/<manufacturer>
/usr/local/lib/printdrivers/<supplier>

and

/opt/printing/ppd/<supplier>/<manufacturer>/
/opt/printing/drivers/<supplier>/

Why are both pairs needed?

   Till

Re: [Printing-architecture] resend notes from last week

[Ian Murdock]

Till Kamppeter wrote:
> Michael Sweet wrote:
>> Till Kamppeter wrote:
>>> Are more directories needed?
>>
>> /usr/local/share/ppd/<supplier>/<manufacturer>
>> /usr/local/lib/printdrivers/<supplier>
>>
> 
> Is it not enough agreeing on one ofthe pairs
> 
> /usr/local/share/ppd/<supplier>/<manufacturer>
> /usr/local/lib/printdrivers/<supplier>
> 
> and
> 
> /opt/printing/ppd/<supplier>/<manufacturer>/
> /opt/printing/drivers/<supplier>/
> 
> Why are both pairs needed?

/usr/local is where system administrators can install printer drivers
(say, downloaded manually from linuxprinting.org), and /opt is where
vendors can install printer drivers (say, installed via an LSB package
downloaded from the vendor's website) that aren't shipped as part of
the operating system. Question: Is /opt/printing consistent with the
FHS? Wouldn't it be /opt/<vendor>? Yes, that means there's no
canonical place for vendors to drop printer drivers so they
are available system-wide, but that's the equivalent problem of
not having a single path element for third-party
executables, and should presumably be solved in the same manner.

(Adding lsb-discuss to this discussion, so we can get FHS feedback.)

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

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

Re: [Printing-architecture] resend notes from last week

[Fujinaka, Todd]

>-----Original Message-----
>From: Till Kamppeter [mailto:till.kamppeter@gmail.com]
>
>Is it not enough agreeing on one ofthe pairs
>
>/usr/local/share/ppd/<supplier>/<manufacturer>
>/usr/local/lib/printdrivers/<supplier>
>
>and
>
>/opt/printing/ppd/<supplier>/<manufacturer>/
>/opt/printing/drivers/<supplier>/
>
>Why are both pairs needed?

I will repeat this again: /opt is for third-party vendors, /usr/local is
for the local sysadmin to install things. These are called out
separately by the FHS.

Both should be included.

Todd

Re: [Printing-architecture] resend notes from last week

[Fujinaka, Todd]

>-----Original Message-----
>From: printing-architecture-bounces@lists.freestandards.org
>[mailto:printing-architecture-bounces@lists.freestandards.org] On
Behalf Of
>Michael Sweet
>
>Till Kamppeter wrote:
>> ...
>> Does this mean that putting a third-party CUPS filter into
>> /usr/lib/cups/filter/ is no violation of FHS?
>
>Technically yes, since they aren't part of the standard printing
>system.  That said, there is a long history of putting drivers
>(or interface scripts, or filters, etc.) in /usr/share, so it
>might make sense to add a grandfather clause for this, or make
>it one of several possible directories - OS vendors put them in
>/usr/share, other vendors in /opt/printing/share, local drivers
>in /usr/local/share, etc.

It is my understanding that /usr/share shouldn't change. I think Till is
forgetting that CUPS is included by the distro, so having things in
/usr/share/CUPS at install time is not a problem.

>> Would then putting a driver and its PPD into the directories
>>
>> /usr/share/ppd/<supplier>/<manufacturer>/
>>
>> and
>>
>> /usr/lib/printdrivers/<supplier>
>>
>> because these directories are a core part of the OS?
>>
>> Or do we still need the alternative location /opt/printing/?
>
>I'd say to support both - /usr for OS-supplied stuff, /opt and
>/usr/local for locally-installed stuff.

It is my understanding nothing should be installed into /usr while the
system is running normally. There are times when packages are updated,
but I think the assumption is that updates are not happening during
"normal use." Also, /usr is the domain of the distro and I doubt they
want you to touch it without their OK.

Thanks,
Todd

Re: [Printing-architecture] resend notes from last week

[Till Kamppeter]

Fujinaka, Todd wrote:
>>-----Original Message-----
>>From: printing-architecture-bounces@lists.freestandards.org
>>[mailto:printing-architecture-bounces@lists.freestandards.org] On
> 
> Behalf Of
> 
>>Michael Sweet
>>
>>Till Kamppeter wrote:
>>
>>>...
>>>Does this mean that putting a third-party CUPS filter into
>>>/usr/lib/cups/filter/ is no violation of FHS?
>>
>>Technically yes, since they aren't part of the standard printing
>>system.  That said, there is a long history of putting drivers
>>(or interface scripts, or filters, etc.) in /usr/share, so it
>>might make sense to add a grandfather clause for this, or make
>>it one of several possible directories - OS vendors put them in
>>/usr/share, other vendors in /opt/printing/share, local drivers
>>in /usr/local/share, etc.
> 
> 
> It is my understanding that /usr/share shouldn't change. I think Till is
> forgetting that CUPS is included by the distro, so having things in
> /usr/share/CUPS at install time is not a problem.
>

But third-party CUPS drivers go into /usr/lib/cupss/filter and
/usr/share/cups/model. So there is third-party software which goes into
/usr.

> 
>>>Would then putting a driver and its PPD into the directories
>>>
>>>/usr/share/ppd/<supplier>/<manufacturer>/
>>>
>>>and
>>>
>>>/usr/lib/printdrivers/<supplier>
>>>
>>>because these directories are a core part of the OS?
>>>
>>>Or do we still need the alternative location /opt/printing/?
>>
>>I'd say to support both - /usr for OS-supplied stuff, /opt and
>>/usr/local for locally-installed stuff.
> 
> 
> It is my understanding nothing should be installed into /usr while the
> system is running normally. There are times when packages are updated,
> but I think the assumption is that updates are not happening during
> "normal use." Also, /usr is the domain of the distro and I doubt they
> want you to touch it without their OK.
> 
So third-party CUPS drivers are violating the standards currently, due
to requirements of CUPS.

   Till

[Printing-architecture] resend notes from last week

[Wendy Phillips]

Apparently, this didn't go out to the alias; could be that I fumbled
it on the keyboard. So here tis again ...

I have purposely not included the follow-on discussions about fhs standard;
this is a summary of the meeting as it occurred.

-Wendy

1. Installation path for ppd files

         /usr/share/ppd/<supplier>/<manufacturer>/

2. PPD file naming convention

         <MFGString>-<MDLString>-<driver>-<language>.ppd

3. Installation path for print drivers

         /usr/lib/printdrivers/<supplier>

         The contents of this directory are entirely determine
         by the supplier. The path to a driver is found by using
         an absolute path in the ppd file.

4. It was agreed that install scripts be written in Bourne Shell
without any extensions.

5.  We decided to eliminate /usr/lib/printdrivers/bin

Re: [Printing-architecture] resend notes from last week

[Till Kamppeter]

Wendy Phillips wrote:
> Apparently, this didn't go out to the alias; could be that I fumbled
> it on the keyboard. So here tis again ...
> 
> I have purposely not included the follow-on discussions about fhs standard;
> this is a summary of the meeting as it occurred.
> 
> -Wendy
> 
> 1. Installation path for ppd files
> 
>          /usr/share/ppd/<supplier>/<manufacturer>/
> 
> 2. PPD file naming convention
> 
>          <MFGString>-<MDLString>-<driver>-<language>.ppd
> 
> 3. Installation path for print drivers
> 
>          /usr/lib/printdrivers/<supplier>
> 
>          The contents of this directory are entirely determine
>          by the supplier. The path to a driver is found by using
>          an absolute path in the ppd file.
> 

Paths in /usr to accomodate 3rd-party software do not comply the FHS
standard. Therefore alternative paths were suggested in other threads.
But note that CUPS violates FHS, too, as CUPS requires drivers in
/usr/lib/cups/filter.

> 4. It was agreed that install scripts be written in Bourne Shell
> without any extensions.
> 

OK.

Is there a compliance test program to check whether one has no bashisms
in the scripts?

> 5.  We decided to eliminate /usr/lib/printdrivers/bin
> 

OK, with absolute paths in the PPDs this is not needed.

   Till

Re: [Printing-architecture] resend notes from last week

[Michael Sweet]

Till Kamppeter wrote:
> Wendy Phillips wrote:
>> Apparently, this didn't go out to the alias; could be that I fumbled
>> it on the keyboard. So here tis again ...
>>
>> I have purposely not included the follow-on discussions about fhs standard;
>> this is a summary of the meeting as it occurred.
>>
>> -Wendy
>>
>> 1. Installation path for ppd files
>>
>>          /usr/share/ppd/<supplier>/<manufacturer>/
>>
>> 2. PPD file naming convention
>>
>>          <MFGString>-<MDLString>-<driver>-<language>.ppd
>>
>> 3. Installation path for print drivers
>>
>>          /usr/lib/printdrivers/<supplier>
>>
>>          The contents of this directory are entirely determine
>>          by the supplier. The path to a driver is found by using
>>          an absolute path in the ppd file.
>>
> 
> Paths in /usr to accomodate 3rd-party software do not comply the FHS
> standard. Therefore alternative paths were suggested in other threads.
> But note that CUPS violates FHS, too, as CUPS requires drivers in
> /usr/lib/cups/filter.

Bzzzt, wrong.

The separation of /usr, /usr/local, and /opt/vendor does not apply
since CUPS provides a core OS function - printing.  If you installed
CUPS in /opt/cups (or like *BSD does, in /usr/local), you'd quickly
find out that a LOT of software expects lp, lpr, etc. in /usr,
leading to VERY frustrated users.  Moreover, the LSB requires the
print commands in /usr, and FHS and LSB are pretty closely tied
together.

That said, nothing would prevent you from making symlinks everywhere,
and Red Hat (at least) did this for a while to allow both LPRng and
CUPS to coexist, but that goes against the intent of /usr being used
as a shared (read-only) filesystem among multiple systems and is just
plain fragile...

The CUPS build system accommodates almost any directory organization,
and if you stick with using --prefix you'll end up with /usr,
/usr/local, or /opt/foo directory structures that follow the FHS
exactly.  You can also relocate individual pieces (like putting
ServerBin in /opt/cups/bin, DataDir in /opt/cups/share, etc.),
but again you will need to do symlinks to preserve compatibility.

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

Re: [Printing-architecture] resend notes from last week

[Till Kamppeter]

Michael Sweet wrote:
> Till Kamppeter wrote:
> 
>> Wendy Phillips wrote:
>>
>>> Apparently, this didn't go out to the alias; could be that I fumbled
>>> it on the keyboard. So here tis again ...
>>>
>>> I have purposely not included the follow-on discussions about fhs
>>> standard;
>>> this is a summary of the meeting as it occurred.
>>>
>>> -Wendy
>>>
>>> 1. Installation path for ppd files
>>>
>>>          /usr/share/ppd/<supplier>/<manufacturer>/
>>>
>>> 2. PPD file naming convention
>>>
>>>          <MFGString>-<MDLString>-<driver>-<language>.ppd
>>>
>>> 3. Installation path for print drivers
>>>
>>>          /usr/lib/printdrivers/<supplier>
>>>
>>>          The contents of this directory are entirely determine
>>>          by the supplier. The path to a driver is found by using
>>>          an absolute path in the ppd file.
>>>
>>
>> Paths in /usr to accomodate 3rd-party software do not comply the FHS
>> standard. Therefore alternative paths were suggested in other threads.
>> But note that CUPS violates FHS, too, as CUPS requires drivers in
>> /usr/lib/cups/filter.
> 
> 
> Bzzzt, wrong.
> 
> The separation of /usr, /usr/local, and /opt/vendor does not apply
> since CUPS provides a core OS function - printing.  If you installed
> CUPS in /opt/cups (or like *BSD does, in /usr/local), you'd quickly
> find out that a LOT of software expects lp, lpr, etc. in /usr,
> leading to VERY frustrated users.  Moreover, the LSB requires the
> print commands in /usr, and FHS and LSB are pretty closely tied
> together.
> 
> That said, nothing would prevent you from making symlinks everywhere,
> and Red Hat (at least) did this for a while to allow both LPRng and
> CUPS to coexist, but that goes against the intent of /usr being used
> as a shared (read-only) filesystem among multiple systems and is just
> plain fragile...
> 
> The CUPS build system accommodates almost any directory organization,
> and if you stick with using --prefix you'll end up with /usr,
> /usr/local, or /opt/foo directory structures that follow the FHS
> exactly.  You can also relocate individual pieces (like putting
> ServerBin in /opt/cups/bin, DataDir in /opt/cups/share, etc.),
> but again you will need to do symlinks to preserve compatibility.
> 

Does this mean that putting a third-party CUPS filter into
/usr/lib/cups/filter/ is no violation of FHS?

Would then putting a driver and its PPD into the directories

/usr/share/ppd/<supplier>/<manufacturer>/

and

/usr/lib/printdrivers/<supplier>

because these directories are a core part of the OS?

Or do we still need the alternative location /opt/printing/?

   Till

Re: [Printing-architecture] resend notes from last week

[Michael Sweet]

Till Kamppeter wrote:
> ...
> Does this mean that putting a third-party CUPS filter into
> /usr/lib/cups/filter/ is no violation of FHS?

Technically yes, since they aren't part of the standard printing
system.  That said, there is a long history of putting drivers
(or interface scripts, or filters, etc.) in /usr/share, so it
might make sense to add a grandfather clause for this, or make
it one of several possible directories - OS vendors put them in
/usr/share, other vendors in /opt/printing/share, local drivers
in /usr/local/share, etc.

> Would then putting a driver and its PPD into the directories
> 
> /usr/share/ppd/<supplier>/<manufacturer>/
> 
> and
> 
> /usr/lib/printdrivers/<supplier>
> 
> because these directories are a core part of the OS?
> 
> Or do we still need the alternative location /opt/printing/?

I'd say to support both - /usr for OS-supplied stuff, /opt and
/usr/local for locally-installed stuff.

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