All of lore.kernel.org
 help / color / mirror / Atom feed
From: Till Kamppeter <till.kamppeter@gmail.com>
To: Christopher Yeoh <cyeoh@samba.org>
Cc: "Wichmann, Mats D" <mats.d.wichmann@intel.com>,
	wendyp@jurassic.eng.sun.com, rusty@samba.org,
	printing-architecture <printing-architecture@freestandards.org>,
	"McDonald, Ira" <imcdonald@sharplabs.com>,
	Wendy Phillips <wendy.phillips@sun.com>
Subject: Re: [Printing-architecture] Proposed filesystem layout for print ppd and driver files
Date: Thu, 03 Aug 2006 15:52:59 +0200	[thread overview]
Message-ID: <44D1FFBB.2060400@gmail.com> (raw)
In-Reply-To: <17617.20772.300641.573886@localhost.localdomain>

So then I would say we go with my last suggestion:

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>/

and the install scripts should by default (asking could be supressed by
a command line option) not overwrite files without asking the user.

Using /opt/share/ppd/<supplier>/<manufacturer>/ and
/opt/lib/printdriver/<supplier>/ for the symlinks should make file
clashes usually not happening. Perhaps we should reserve these with LANANA.

   Till


Christopher Yeoh wrote:
>>>"The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib,
>>>and /opt/man are reserved for local system administrator use. Packages
>>>may provide "front-end" files intended to be placed in (by linking or
>>>copying) these reserved directories by the local system administrator,
>>>but must function normally in the absence of these reserved
>>>directories."
>>>
>>>(so it doesn't mention /opt/share explicitly but it seems
>>>like the intent is clear)
>>>
>>
>>Does this mean that for third-party vendors only
>>
>>/opt/<supplier>/
>>
>>is allowed and nothing outside of this?
>>
> 
> 
> No, symlinks are fine, but probably should be installed as part of a
> post-install script with permission from the sysadmin.
> 
> Just to add a bit of background, /opt/<vendor|package> was created to
> avoid namespace clashes. The ability to copy/symlink to say /opt/bin
> (and it really probably should be only symlinking) was added so user's
> paths didn't need to be modified for every package that was installed.
> 
> So I'd like to keep the current practice of only installing into
> /opt/<vendor>, and creating symlinks from /opt/lib or /opt/share to
> make things easier for applications that need find the ppd or driver
> files.
> 
> This, I think is the solution that best matches the current design of
> the /opt in the FHS, even though it is a bit more complex than just
> installing direct into /opt/lib or /opt/share.
> 
> In practice, the "permission from the sysadmin" is perhaps not needed
> for the symlinking pppd files *if* something like LANANA can guarantee
> no namespace clashes. But packages should be very careful never to
> overwrite existing links.
> 
> Chris


  reply	other threads:[~2006-08-03 13:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3F62CBEE02D6404E98C65934617EB58254DED6@fmsmsx414.amr.corp.intel.com>
2006-08-02 16:41 ` [Printing-architecture] Proposed filesystem layout for print ppd and driver files Till Kamppeter
2006-08-03  1:28   ` Christopher Yeoh
2006-08-03 13:52     ` Till Kamppeter [this message]
     [not found] <3F62CBEE02D6404E98C65934617EB582586CB7@fmsmsx414.amr.corp.intel.com>
2006-08-03 14:39 ` Till Kamppeter
2006-08-02 16:18 McDonald, Ira
2006-08-02 16:25 ` Till Kamppeter
  -- strict thread matches above, loose matches on Subject: below --
2006-07-27  0:43 Wendy Phillips
2006-07-27  4:29 ` Christopher Yeoh
2006-08-02 16:05   ` Till Kamppeter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44D1FFBB.2060400@gmail.com \
    --to=till.kamppeter@gmail.com \
    --cc=cyeoh@samba.org \
    --cc=imcdonald@sharplabs.com \
    --cc=mats.d.wichmann@intel.com \
    --cc=printing-architecture@freestandards.org \
    --cc=rusty@samba.org \
    --cc=wendy.phillips@sun.com \
    --cc=wendyp@jurassic.eng.sun.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.