Re: Binaries outside /usr/bin (Was: r7694 - trunk/packages/seqan/trunk/debian)
Le Wed, Sep 07, 2011 at 09:52:30AM +0200, Andreas Tille a écrit :
> 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.
My problem with this approach (and similarly with removing some suffixes in
some file names, typically ‘.pl’) is that the scripts and documentation become
specific to Debian. In my workplace where I am one of the only persons to
use Debian, it is typically a problem.
> 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
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)
(or any complicated variant that features proper sanity and security checks).
Cheers,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
Reply to: