Re: Solving name space polution problems in Blends? (Was: /usr/lib/ns/med/bin ?)
-----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-----
Reply to: