Solving name space polution problems in Blends? (Was: /usr/lib/ns/med/bin ?)
- To: Debian Med Project List <email@example.com>
- Cc: Debian Pure Blends List <firstname.lastname@example.org>, Petter Reinholdtsen <email@example.com>
- Subject: Solving name space polution problems in Blends? (Was: /usr/lib/ns/med/bin ?)
- From: Andreas Tille <firstname.lastname@example.org>
- Date: Wed, 8 Apr 2009 15:38:59 +0200 (CEST)
- Message-id: <alpine.DEB.2.00.0904081521250.2476@wr-linux02>
- In-reply-to: <49DC945E.email@example.com>
- References: <49DC945E.firstname.lastname@example.org>
[For the users of the Debian Blends list who do not understand the motivation
of this mail just read http://bugs.debian.org/503367.]
On Wed, 8 Apr 2009, Steffen Moeller wrote:
I recall from a visit at City University in London that they had just the basic tools in
their default paths and added specialised software only upon the execution of some script.
I did not like this back then, but with the hindsight of the conflicts with plink, I feel
that this is rather helpful to have.
I think this solution can/should be done *if* *needed* on a case by case basis.
There may be better paths than /usr/lib/ns/med/bin. What is the feeling on the list about
such a solution?
IMHO this is just a "suggestion" and not yet a "solution". A solution would include
specifying how you want to acomplish this. Do you intend all packages maintained
by Debian Med team to place symlinks to this dir? Do you think the metapackages
should try some magic to acomplish this or whatever?
IMHO there is no need to push *all* med packages to this dir. If a package is
not found there it will be found in the default path anyway. Or do I miss
So using a directory /usr/lib/ns/med/bin (or whatever it might be named see below)
is only needed if there is *really* some name space polution. If this is the
case it might make sense to symlink the original name to some directory and include
this dir into your PATH. If we want to solve this inside the Blends scope I would
suggest to use
(Hmmm, /usr/share should work if we use only symlinks - if not we need to use
/usr/lib.) 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 (based on UNIX user groups which is kind of insufficient - but this
has t be dicsussed in another thread) 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.
I'm not against trying to help Blends users but I would like to discuss this
here with the background of the above considerations. I remember an interesting
talk of Petter in Helsinki (?) about per user configuration which somehow targets
in the same direction. Petter, can you comment on this?