Binaries outside /usr/bin (Was: r7694 - trunk/packages/seqan/trunk/debian)

[Andreas Tille <andreas@an3as.eu>]

[Moving discussion to general Debian Med list to possibly get some input
 from users]

On Wed, Sep 07, 2011 at 03:47:42PM +0900, Charles Plessy wrote:
> Some of the programs names are not generic, some are borderline and some are
> clearly generic.  I do not want to make the call.  Also, each time we remove a
> program from /usr/bin, we risk to break an user's script or documentation on
> upgrades.  Therefore, in the absence of file conflicts, I think that if we
> rename we should at least provide a transitional link for one release cycle.

This is a valid argument - however, in the same line of argumentation it
might be people start writing now scripts using the links in /usr/bin
and relay on having scripts there from now on.  I personally have no
interest to change anything - just adding some thoughts to consider.
 
> More in general, I think that the PATH trick is not scalable.  We really need a
> way to let the users install packages in their area of interest with
> executables in the default path even if the names are generic, as long as there
> is no local conflict.

This topic comes up regularly in such cases.  I think we can state as a
fact that we will just have cases where a binary can not placed in
/usr/bin (for different reasons) and we need to find a way to help users
to get them in their PATH automatically.

To do so we need to answer some questions:  Do we want to

  A) Help the user of the single package  or
  B) Do we want to help the Debian Med user (which is somehow defined
     as somebody who installs the med-* metapackages.

For A) I do not see a good policy compliant solution.  For Debian Med or
more generally for Blends (I will stick to the med-* example in the
following but I will foreward a suggestion to the Blends list once we
might have settled down to something reasonable) I could assume the
following:

  1. med-foo drops a file
       /etc/profile.d/med-foo
     containing
       export PATH=/usr/share/blends/med/wrappers/foo:$PATH
  2. Package med-foo has a list of directories
       /usr/share/blends/med/wrappers/foo.dirs
     which lists all directories that might contain binaries
     of packages which can not be moved to /usr/bin
  3. Package med-config contains a Post-Invoke statement
     which will be dropped into
       /etc/apt/apt.conf.d
     which scans those directories after the installation of
     packages to refresh the links.  IMHO this is needed to
     make sure that changes in packages are reflected
     automatically without needing to reinstall med-foo

I'm a bit unsure whether we need to distinguish into
   /usr/share/blends/med/wrappers/foo
or whether we could go with
   /usr/share/blends/med/wrappers
and put the general list for all Debian Med tasks into
   /usr/share/blends/med/wrappers.dirs
in the package med-config - this would be a bit simpler and
would work as well.

In this way Debian Med users (= those who are using the med-*
metapackages) will find the packages in their focus in the first place
in their PATH (accepting that binaries with the same name in /usr/bin
are masqueraded and possibly breaking other scripts which are not using
explicite path to /usr/bin).

The careful reader might have noticed my suggestion has a big flaw: UNIX
systems are multi-user systems and it is simply wrong that users who
login to a system which (by chance!) has installed any med-* package
are considered Debian Med users and get their PATH tweaked.  So the
correct solution is to NOT assume that a user is a Debian Med user but
rather check whether a specific user is declared to be a Debian Med
user which is possible in the configuration step of med-config.  You
can check this via

   sudo dpkg-reconfigure med-config

The according question is asking about user menus and either needs to be
reworded or needs an additional question regarding changed PATH for
those users that can be selected afterwards.  Considering the fact that
those user menus at best do not harm and are widely ignored in the
current form I would just suggest to reword this question somehow

  "Which users of your system are Debian Med users.  These users will
  get an extra Debian user menu and their PATH will be adapted to prefer
  Debian Med applications"

While this solution is better than ignoring the multi-user nature of a
UNIX system at all it has a big design flaw:  Currently the technique
works only for UNIX groups.  An implementation for LDAP (or other
authentication methods) is just missing (volunteers? :-)).  Moreover the
question is not repeated once new users will be added to the system and
either the admin sets the debian-med group membership manually or
reconfigures med-config.  I have no idea whether adduser might feature
regarding some hooks to be called after a new user was created - this
might be a reasonable thing to do.

In case somebody would like to say: "Come on, in 'usual' cases we just
have single user machines" I have a quite simple answer: I will simply
not implement a dirty hack which disrespects basic principles.  First
define what you mean with 'usual' and if you manage to find a definition
for this we might consider to set a flag somewhere which might simplify
things on such 'usual' machines.  In any case in the common Blends scope
we need to respect the multi-user nature of UNIX systems and can not
simply change the PATH of a random user.

Any thoughts?

Kind regards

      Andreas.

-- 
http://fam-tille.de