On Wed, Sep 30, 2009 at 08:02:57AM +0200, Mike Hommey wrote:
>
> That would mean a possibly overlong PATH. A single place for those
> scripts would be better.
That's what I meant when I wrote
/usr/not_policy_compliant_named_dust-bin/ [1]
I kept on thinking about this issue and I wonder whether there is a
chance to find a pragmatical solution in the Blends scope. Knowing that
the initiator of this thread comes form Debian Med Blend and considering
the fact that you might frequently find specific applications in a
certain field and external scripts / programs that are using this API in
the same field of work. Moreover the Blends maintainer team has control
or at least a good overview about the packages in the field. So we
might do the following:
1. Install the policy compliant named executable to /usr/bin
2. Symlink to this from /usr/share/<Blendname>/bin with the
name choosen by upstream.
3. Use /etc/profile.d/<Blendname> to extend the path
(I just realised that lsb-core package installs /etc/profile.d
and notice that the suggestion I wanted to make here is just
implemented. I definitely have to read about its usage but
it is exactly what I wanted to implement to extend the PATH
reasonably.)
There are plans to differentiate system users of a machine whether they
should get the Blend specific settings or not. Currently this is
implemented for the user menu system based on users in /etc/passwd but
this method sucks for several reasons and has to be enhanced. But a
way to do this settings for a certain set of users will be implemented
sooner or later - so the question if everybody gets this PATH extension
should be dealt with in the future.
Kind regards
Andreas.
[1] http://lists.debian.org/debian-devel/2009/09/msg01016.html
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
