[Printing-architecture] Proposed filesystem layout for print ppd and driver files

McDonald, Ira imcdonald at sharplabs.com
Wed Aug 2 09:18:45 PDT 2006


Hi Till,

I mostly agree with this set of directory paths - thanks for
writing up the summary.

I think that full FHS compliance is important - partly because
it's a requirement for inclusion in LSB - and partly because
I dislike "reinventing the wheel".

Except that I do NOT agree that the symlinks should be
mandatory - if a print software vendor wants to store
directly and ONLY in '/opt/share/ppd/<supplier>/<mfg>',
that is sufficient and _preferable_ to the creation of
more '/opt/<supplier>' directories for a useless level
of indirection.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com

> -----Original Message-----
> From: printing-architecture-bounces at lists.freestandards.org
> [mailto:printing-architecture-bounces at lists.freestandards.org]
> On Behalf
> Of Till Kamppeter
> Sent: Wednesday, August 02, 2006 12:05 PM
> To: Christopher Yeoh
> Cc: rusty at samba.org; mats.d.wichmann at intel.com;
> wendyp at jurassic.eng.sun.com; printing-architecture; Wendy Phillips
> Subject: Re: [Printing-architecture] Proposed filesystem layout for
> print ppd and driver files
> 
> 
> I would like to agree on a directory layout for printing this 
> week. What
> do you think about Chris' suggestions
> 
> Distro-supplied:
>   /usr/share/ppd/<supplier>/<manufacturer>/
>   /usr/lib/printdriver/<supplier>/
> 
> Vendor-supplied:
>   /opt/share/ppd/<supplier>/<manufacturer>/ be a symlink to
>     /opt/<vendor>/<undefined_place_in_hierarchy>
>   /opt/lib/printdriver/<supplier>/ be a symlink
>     /opt/<vendor>/<undefined_place_in_hierarchy>
> 
> Local admin:
>   /usr/local/share/ppd/<supplier>/<manufacturer>/
>   /usr/local/lib/printdriver/<supplier>/
> 
> to be completely FHS compliant?
> 
> Is it really not possible to get the stuff in /opt somewhat 
> simpler and
> stay FHS compliant?
> 
> All the rest (file names, scripts, ...) should stay as we 
> already agreed on.
> 
>    Till
> 
> 
> Christopher Yeoh wrote:
> > Hi Wendy,
> > 
> > (Added Rusty to the CC list since he is also an FHS editor)
> > 
> > At 2006/7/26 17:43-0700  Wendy Phillips writes:
> > 
> >>As a result of the past weeks discussion and the fsg architecture 
> >>meeting today, the following proposal is on the table. It defines 
> >>directories for ppd files and print drivers; placement of 
> files is based 
> >>on category of provider: distribution, third party vendor, 
> and system 
> >>administrator.
> > 
> > 
> >>From an FHS point of view I think the proposal is inconsistent.
> > Currently there is symmetry between /usr, /usr/local and /opt.
> > 
> > Eg if something would normally go in /usr/lib if shipped as part of
> > the distribution, then it would go into /usr/local/lib if compiled
> > locally or /opt/lib (via a symlink) if through a 3rd party package.
> > 
> > We'd need a pretty good reason to break that convention.
> > 
> > Also, I'd reiterate that I don't believe a print subdirectory is
> > needed for the /usr/local and /opt hierarchies.
> > 
> > 
> >>1. Distro supplied files
> >>
> >>         The filesystem layout as utilized by the 
> distibutions when the
> >>         ppd files and print drivers are initially 
> installed on the 		 
> >>system. It is presumed that this will also be used for 
> patches 			and 
> >>updates created and delivered by the distro.
> >>
> >>         a. Installation path for ppd files
> >>                 /usr/share/ppd/<supplier>/<manufacturer>/
> >>
> >>         b. Installation path for print drivers
> >>                 /usr/lib/printdriver/<supplier>
> >>
> > 
> > This looks fine.
> > 
> > 
> >>2. Third Party Vendor supplied files
> >>
> >>         The filesystem layout to be utilized by third party vendors
> >>         for delivery of ppd files, print drivers and other vendor
> >>         supplied files.
> >>
> >>         a. Installation path for PPD files
> >>                 /opt/print/ppd/<supplier>/<manufacturer>
> >>
> >>         b. Installation path for print drivers
> >>                 /opt/print/driver/<supplier>
> >>
> > 
> > I'd suggest instead
> > 
> > /opt/share/ppd/<supplier>/<manufacturer>/<ppd_file> be a 
> symlink to /opt/<vendor>/<undefined_place_in_hierarchy>
> > 
> > and 
> > 
> > /opt/lib/printdriver/<supplier>/<print_driver_filename> be 
> a symlink to /opt/vendor/<undefined_place_in_hierarchy>
> > 
> > 
> > Currently *nothing* installs directly under /opt, outside of
> > /opt/<vendor> (except for symlinks) and we'd need a good reason to
> > change that.
> > 
> > 
> >>3. Files created, downloaded, or modified by a system administrator.
> >>
> >>         a. Installation path for PPD files
> >>                 /usr/local/print/ppd/<supplier>/<manufacturer>
> >>
> >>         b. Installation path for print drivers
> >>                 /usr/local/print/driver/<supplier>
> >>
> > 
> > and here:
> > 
> > /usr/local/share/ppd/<supplier>/manufacturer/
> > 
> > and
> > 
> > /usr/local/lib/printdriver/<supplier>
> > 
> >>4. Common features
> >>         These features apply to each of the three supplier 
> categories,
> >>         distro, third party vendor, and administrator.
> >>
> >>         a. PPD file naming convention
> >>                 <MFGString>-<MDLString>-<driver>-<language>.ppd
> > 
> > 
> > are the mfgstring and mdl strings always going to be unique between
> > suppliers and manufacturers? If so the supplier and manufacturer
> > subdirectories can be dropped for the ppd files - which would simply
> > things somewhat for applications.
> > 
> > 
> >>         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.
> > 
> > 
> > If the path to the driver directory is always determined by the
> > contents of the ppd file, and applications should never be 
> capable of
> > finding them through other means, then for /opt we don't need to
> > specify a path for where they are installed. They can simply live
> > somewhere under /opt/<vendor> (exactly where up to the vendor's
> > discretion)
> > 
> > 
> >>         c. Install scripts must be  written in Bourne Shell without
> >>         any extensions.
> > 
> > 
> > I would suggest restricting to the commands and utilities 
> to usage as
> > specified in the LSB specification (the LSB requires a 
> POSIX shell, so
> > maybe do not allow bash extensions).
> > 
> > 
> >>5. Precedence Rules
> >>         Highest precedence is given to the system 
> administrator which
> >>         allows for system by system modfications as determined by
> >>         support personel.
> >>
> >>         PPD files
> >>         Admin :                 /usr/local/print/ppd    Highest
> >>         Third Party Vendor :    /opt/print/ppd
> >>         Distro :                /usr/share/ppd          Lowest
> >>
> >>         Drivers
> >>         Admin :                 /usr/local/print/driver Highest
> >>         Third Party Vendor :    /opt/print/driver
> >>         Distro :                /usr/lib/printdriver    Lowest
> > 
> > 
> > Precendence rules look good. Though if drivers are always discovered
> > through ppd files do you need to specify precedence rules 
> for them? Or
> > if only a driver and not a ppd file is installed under /usr/local do
> > you expect the application to find it even though the ppd file
> > specifies one in /usr/lib/printdriver ?
> > 
> > btw are there distribution representatives on the
> > printing-architecture mailing list? Because we really do need
> > agreement from them on whatever gets settled upon.
> > 
> > (am on planes for the next couple of days so may be slow in 
> replying)
> > 
> > Regards,
> > 
> > Chris
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture at lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/printing-architecture
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.5/405 - Release Date: 8/1/2006
 




More information about the Printing-architecture mailing list