Re: Binaries outside /usr/bin (Was: r7694 - trunk/packages/seqan/trunk/debian)
FWIW, having the same pain, for similar packages in neuroscience domain
e.g. FSL, and AFNI (not yet in Debian proper, only neurodebian) we (or
primarily Michael ;-) ) have decided to go with
1. shipping /etc/pkg/pkg.sh
which sets PATH and whatelse needed for proper operation
of the toolkit
2. in README.Debian requiring interested users to source that file in
their .profile or .bashrc
3. some times providing wrappers or symlinks under /usr/bin/ only
for few most-often used and unique tools (e.g. GUI frontends)
reasons are exactly the ones already outlined: language suffixes (.pl,
.py, .sh), conflicts, and evilness of polluting bin-namespace on
multi-user systems. In many cases upstream anyways require users to
source similar environment-setting scripts, so such setup doesn't
diverge much from upstream leaving everyone happy.
Moreover, for some packages (e.g. FSL) we converged on having versioned
packages, so multiple versions of the same software become available
(with a meta-package tracking the most recent available).
Without having any files under /usr/bin such co-installation becomes
possible without hassle and corresponding version could be used by
sourcing a corresponding /etc/pkg/version/pkg.sh . I know that it feels
stepping away from "Debian way" to do things, but it seems to be the
only viable solution for such cases.
just 1 comment for the below: there would be no guarantee of having no
namespace conflicts among med-specific tools either, so a
mass-sourcing of /etc/blends/med/path.d might also lead to some
unpleasant overrides ;-)
On Mon, 12 Sep 2011, Andreas Tille wrote:
> > This would require the blends packages to be updated each time
> > a package starts to rename its programs. Perhaps the packages
> > themselves could declare directly to the blends:
> > 1. foo drops a file in /etc/blends/med/path.d, that contains
> > something like ‘export PATH=/usr/lib/foo/bin:$PATH’.
> > 2. Debian Med users source /etc/blends/med/path.d in their shell
> > initiation scripts (this obviously exclude csh and its derivatives)
> This might be another alternative approach to consider. Any opinions?
> Kind regards
> Andreas.
--
=------------------------------------------------------------------=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic
Reply to: