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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
