On Wed, 29 Oct 2008, Charles Plessy wrote:
I think that I would like the Debian Blend distributions (formerly called CDDs)
to manage this smartly in the future. We could have some mechanisms that make
sure that for biologists, plink relates to SNPs, not to SSH. But this is a long
term goal with no implementation plan.
Well, an implementation plan could be to symlink any binary to a
/usr/share/blends/<blendname>/bin
directory and adjust PATH for those users who are registered as
user of this blend - so I see no problem in principle to realise
this idea. But I'm absolutely not happy about such kind of workarounds.
As I explained earlier it is also about name space polution in the
Free Software namespace - it makes no sense to find a Debian specific
or a Blend specific solution and should be avoided in general.
If we are confident that the user sets of
plink and putty are mutually exclusive,
We can and should not be confident about this - neither in this specific case
nor in general.
I would not mind a Conflict even if it
is not allowed by the Policy. But how confident are we that we will not get
complains? We will be in a much worse situation if we have to make changes
after our userbase is established.
Yes - that's why we should also care for users which are not yet users of
Debian - finally they will all use Debian once we reached world domination. ;-)
I personnaly would advocate d) because it can be the basis for a more global
solution later. For instance something like /usr/lib/debian-med/plink ->
/usr/lib/plink/plink, and populating /usr/lib/debian-med/ with our other cases
of namespace pollutors-polluted programs. We could then ask our users to put
/usr/lib/debian-med/ in their paths, so that they do not have to micromanage
such issues.
Something like this as I mentioned above. The per package /usr/lib
solution is just established and accepted but only a Debian specific
workaround.
Lastly, Upstream was very responsive; we probably should discuss again with him.
Pointing upstream to the mails collected inside the bug page might be
reasonable to understand all arguments.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
