-----BEGIN PGP SIGNED MESSAGE----- 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. Suggestion: 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 them... 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 suggestions.) 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkncufIACgkQn7DbMsAkQLhd1QCfVsJX1qt73PGt4kkxWRTyOQgA qNQAn3h4/MEw4SA5zih+WtOE1ybAwepz =TTes -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
