From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <44D0CD44.3090702@gmail.com> Date: Wed, 02 Aug 2006 18:05:24 +0200 From: Till Kamppeter MIME-Version: 1.0 References: <44C80C19.6040700@sun.com> <17608.16706.402317.393006@localhost.localdomain> In-Reply-To: <17608.16706.402317.393006@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Printing-architecture] Proposed filesystem layout for print ppd and driver files List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christopher Yeoh Cc: rusty@samba.org, mats.d.wichmann@intel.com, wendyp@jurassic.eng.sun.com, printing-architecture , Wendy Phillips 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/// /usr/lib/printdriver// Vendor-supplied: /opt/share/ppd/// be a symlink to /opt// /opt/lib/printdriver// be a symlink /opt// Local admin: /usr/local/share/ppd/// /usr/local/lib/printdriver// 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/// >> >> b. Installation path for print drivers >> /usr/lib/printdriver/ >> > > 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// >> >> b. Installation path for print drivers >> /opt/print/driver/ >> > > I'd suggest instead > > /opt/share/ppd/// be a symlink to /opt// > > and > > /opt/lib/printdriver// be a symlink to /opt/vendor/ > > > Currently *nothing* installs directly under /opt, outside of > /opt/ (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// >> >> b. Installation path for print drivers >> /usr/local/print/driver/ >> > > and here: > > /usr/local/share/ppd//manufacturer/ > > and > > /usr/local/lib/printdriver/ > >>4. Common features >> These features apply to each of the three supplier categories, >> distro, third party vendor, and administrator. >> >> a. PPD file naming convention >> ---.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/ (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