[Printing-architecture] directory structure / file name
imcdonald at sharplabs.com
Fri Jul 14 08:26:37 PDT 2006
Staying conformant to FHS (required for LSB conformance)
appears to need some significant thought and modifications
to our previous FSG/OP concensus (see Wendy Phillips' note
For those having trouble finding the authoritative source
for the FHS spec (I did), below is the home page:
The most recent release is v2.3 (29 January 2004) - there
are links for PDF, PS, HTML, etc. versions of FHS/2.3 on
the above web page.
Does anyone know if there is work-in-progress for a newer
version of FHS? Thirty months is a long time in computers.
I don't think the FSG/OP should recommend a hierarchy std
for printing that is broken across the 'shipped with system'
versus 'later vendor packages'. But I suspect that's just
what Debian, SUSE, and others want, for security reasons.
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
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 Fujinaka, Todd
> Sent: Thursday, July 13, 2006 12:44 PM
> To: Till Kamppeter
> Cc: printing-architecture at lists.freestandards.org
> Subject: Re: [Printing-architecture] directory structure / file name
> >-----Original Message-----
> >From: Till Kamppeter [mailto:till.kamppeter at gmx.net]
> >Some questions:
> >- Should we also have similar alternatives for
> >Theoretically driver could be put anywhere with absolute
> paths in PPDs,
> >but for enhanced security environments it is important to
> have them at
> >determined places and also for the drivers themselves we must be FHS
> Yes. I was just focusing on the PPD files because I thought I
> should get
> the idea out first.
> >- Can we use /opt/printing instead of /opt/openprinting, as the
> >drivers/PPDs do not come from FSG OpenPrinting.
> It's really supposed to be /opt/<vendor>. I think /opt/openprinting
> would be in the spirit of that, but /opt/printing would require some
> discussion with the FHS.
> >- "/usr is shareable, read-only data" for me would only mean
> that while
> >running programs this should not be written, but software
> packages can
> >be installed here. Is there another clause in the FHS
> telling that only
> >software of the OS distribution can be installed here?
> This is just the understanding I have from Debian developers who are
> held to the FHS standard. They told me that /usr is read-only, but you
> can write to it to update things that are there already. It's
> questionable whether new packages can be written there, but
> an OS vendor
> can probably get away with installing things in /usr on their own OS.
> >- There is still one problem with integrating these directories with
> >CUPS: If a printer needs a special backend for the low-level
> >communication, like for example the "hp" CUPS backend for the HP
> >printers used with HPLIP, dropping them into something like
> >/usr/lib/print-drivers/<supplier>/ will not work, as CUPS
> looks only in
> >/usr/lib/cups/backend and absolute paths as device URI are not
> > How can one solve this problem.
> Printing-architecture mailing list
> Printing-architecture at lists.freestandards.org
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date: 7/13/2006
More information about the Printing-architecture