Re: Solving name space polution problems in Blends? (Was: /usr/lib/ns/med/bin ?)
Jonas Smedegaard wrote:
> [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*.
My original feeling was more towards installing packages whose binaries are
not reached via the $PATH at all. For every shell started, one would first need to
source some LD_LIBRARY_PATH and PATH magic to get what would otherwise be available
upfront. But I like the idea to start some of those ENV-amending scripts by default.
To link from one binary to another, one would need to specify the full path of either.
With conflicts in the name of shared libraries, we should hope for different sonames
or we would need to introduce the Rpath, which few of us want, so I presume.
Well, I am with Andreas - to have packages installing to separate name spaces
should be a rare exception.
Steffen
Reply to: