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

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

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

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


[1] http://lists.debian.org/debian-devel/2009/09/msg01016.html


Reply to: