Re: [Printing-architecture] [lsb-discuss] resend notes from lastweek

Re: [Printing-architecture] [lsb-discuss] resend notes from lastweek

[Till Kamppeter]

Wichmann, Mats D wrote:
> possibly we also want freestandards-fhs-discuss@lists.sourceforge.net
> (added with this message) as it's the official list of FHS.
> 
> it's possible we could conceive a less scattered scheme for
> printer drivers - I'm envisioning something like reserving
> /opt/printing with LANANA, then providing a way to manage
> that namespace so it can be shared, perhaps through a second
> registry.
> 

This means that if LANANA registers /opt/printing we can agree on only
the pair

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

as the only PPD/driver directories?

   Till

Re: [Printing-architecture] [lsb-discuss] resend notes from lastweek

[Fujinaka, Todd]

>-----Original Message-----
>From: lsb-discuss-bounces@lists.freestandards.org [mailto:lsb-discuss-
>bounces@lists.freestandards.org] On Behalf Of Christopher Yeoh
>
>At 2006/7/25 15:06+0200  Till Kamppeter writes:
>> Wichmann, Mats D wrote:
>> > it's possible we could conceive a less scattered scheme for
>> > printer drivers - I'm envisioning something like reserving
>> > /opt/printing with LANANA, then providing a way to manage
>> > that namespace so it can be shared, perhaps through a second
>> > registry.
>> >
>>
>> This means that if LANANA registers /opt/printing we can agree on
only
>> the pair
>>
>> /opt/printing/ppd/<supplier>/<manufacturer>/
>> /opt/printing/drivers/<supplier>/
>>
>> as the only PPD/driver directories?
>
>So am I correct in assuming that the files if shipped as part
>of a distribution normally go into:
>
>/usr/share/ppd
>/usr/lib/drivers
>
>If there is distro agreement here, we should get this put into the FHS
>as well.
>
>I'm not convinced that we need to add /opt/printing
>
>The /opt/<vendor> technique should still work, and for convenience
>symlinks can be created in /opt/share/ppd and /opt/lib/drivers to the
>actual files. If you use LANANA, strictly speaking you could just
>install straight into /opt/share and /opt/lib because you know there
>won't be any clashes, but I'd still strongly recommend using symlinks
>instead as it keeps the design simpler and consistent.

The argument for /opt/printing is a compromise. OpenPrinting wanted to
put everything in /usr/share and /usr/lib, and I told them that 3rd
party vendors who add things after the distro should NOT be using /usr
(at least that was my understanding).

However, OpenPrinting wants a standard directory for PPDs and drivers,
so they can tell a 3rd-party vendor that there is one place to look for
those things. I pointed out that they couldn't touch /usr, and they
needed /opt/<vendor> and then suggested /opt/printing/<vendor> when the
first was thought to be too scattered.

I had not been able to find an FHS person or active mailing-list to
bounce these ideas off of and that's another reason that some of these
suggestions are a bit off.

Todd

Re: [Printing-architecture] [lsb-discuss] resend notes from lastweek

[Till Kamppeter]

Christopher Yeoh wrote:
> 
> Yea, I agree /opt/vendor appears scattered, but symlinking them in
> through into /opt/lib/ and /opt/share/ should bring them all together
> without the need for adding a special printing directory to /opt. I'd
> like to avoid having a special case here unless it can be shown to be
> really necessary.
>

Would /opt/share/ppd/<supplier> and /opt/lib/printerdrivers/<supplier>
violate the FHS or can we define this as the standard places for
third-party files?

> Note that although 3rd party vendors will only have to install into
> one place, applications that look for them will still need to look in
> /usr/lib and /usr/local/lib in addition to /opt and at a higher level
> someone will need to work out precedence rules (say /usr/local ->
> /opt/ -> /usr in order of decreasing importance)

In a typical Linux distro with CUPS /usr/share/cups/model will contain
symlinks to /usr/share/ppd, /usr/local/share/ppd, and /opt/share/ppd and
so it will see all PPDs. The drivers are found by absolute paths in the
PPDs. Problem is how will CUPS handle priorities. If there are three
PPDs with equal NickNames but in different directories, the web
interface will show three equal list entries.

The priorities you suggested are good. /opt overrides /usr and so
manufacturer drivers (or updates downloaded as LSB packages from
linuxprinting.org) have priority against distro-included drivers. With
/usr/local having highest priority, drivers installed from source, for
example hacked by the admin will be preferrably used. So admins do not
need to wonder why their patches or CVS updates to not work due to the
distro's version of the driver still being installed.

> freestandards-fhs-discuss@lists.sourceforge.net is the best place for
> FHS discussions. Apologies if I hadn't responded to you before, but
> for some reason SourceForge unsubscribed me from the list and I didn't
> realise (I'm an FHS person). We go through periods of not much
> activity until there is enough in the queue to justify a new release.

Would the suggestion with /opt/share/ppd/<supplier> and
/opt/lib/printerdrivers/<supplier> for third-party drivers need a change
on FHS?

   Till

Re: [Printing-architecture] [lsb-discuss] resend notes from lastweek

[Till Kamppeter]

Christopher Yeoh wrote:
> 
> Yea, I agree /opt/vendor appears scattered, but symlinking them in
> through into /opt/lib/ and /opt/share/ should bring them all together
> without the need for adding a special printing directory to /opt. I'd
> like to avoid having a special case here unless it can be shown to be
> really necessary.
> 
> We would of course need agreement from all of the major distributions
> before adding this to the FHS.
> 
> Note that although 3rd party vendors will only have to install into
> one place, applications that look for them will still need to look in
> /usr/lib and /usr/local/lib in addition to /opt and at a higher level
> someone will need to work out precedence rules (say /usr/local ->
> /opt/ -> /usr in order of decreasing importance)
> 

I got the following suggestion from a De Zeurkous <zeurk (at) xs4all.nl>:

------------------------------------------------------------------------
Personally I'd suggest using /usr/opt for this kind of cases, and put all
the relatively generic data in there -- libraries in /usr/opt/lib, manual
pages in /usr/opt/man, perhaps binary symlinks to /usr/opt/bin instead of
in /usr/bin, etc. For the vendor-specific issue, i'd suggest just adding
the supplier tag as a directory and then symlinking back --
/usr/opt/lib/printerdrivers/foo -> /usr/opt/lib/acme/foo and so on.

De Zeurkous
-----------

------------------------------------------------------------------------

I think this is somewhat strange, is this FHS compliant?

   Till