[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Solving name space polution problems in Blends? (Was: /usr/lib/ns/med/bin ?)

Hash: SHA1

[Let's limit cross-posting: reply-to set to the blends list!]

On Wed, Apr 08, 2009 at 03:38:59PM +0200, Andreas Tille wrote:
> The rationale is that /usr/share/blends/<blendname>/ just exists to 
> store Blend specific user menus and at least in principle there is 
> some role system [...] which presents the menu only to users who have 
> this role.  The users in this role can be defined via a debconf 
> question in <blend>-config.  This would enable tweeking the PATH for 
> all users in this role and make the extra binaries only visible for 
> them.
> IMHO this fits Steffens suggestion somehow.
> But please consider that this solution does not work for those users 
> who just install the problematic packages without the blends specific 
> metapackages.  Assume some user installs the package plink without 
> installing med-bio (and thus med-config per resilved dependency) und 
> this is not a member of the role med?  The user will not profit from 
> this "solution" neither does this work for other packages outside the 
> scope of Debian Blends.  Considering this I think the name space 
> polution problem is somehow orthogonal to the Blends effort.  Even if 
> we might serve a solution for Blends users the problem is not solved 
> in general.

Packages should by default make applications available in the shared 
namespace, according to FHS.  This is required by Debian Policy 9.1.


a) blend-aware packages can optionally install its applications in a 
package-private directory, if it also...

   1) offers a scriptable interface to symlink to namespaces
   2) registers that it exist (e.g. `touch /usr/share/blends/PKG/$pkg`)
   3) checks and invokes blend-update-packages in postinst
   4) symlinks to shared namespace if blend-update-packages is missing

b) blends-common provides /usr/sbin/blend-update-packages, which 
collects a list of registered blend-aware packages and for each of 

   1) enables package for each group of each blend requesting it
   2) enables package for shared namespace unless explicitly disabled

c) blends-common contains a config option (e.g. in /etc/default/blends) 
of whether shared namespace should also be enabled for blend-aware 
applications, or only blends requesting it.  By default shared namespace 
should be *enabled*.

(I must admit that I have not read the referenced discussion.  I 
apologize ahead for the noise, if I am in fact duplicating existing 

Kind regards,

  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
Version: GnuPG v1.4.9 (GNU/Linux)


Reply to: