[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] Package build time config for installation directories.



Manoj Srivastava <srivasta@debian.org> wrote:
>>>"Raul" == Raul Miller <moth@debian.org> writes:
> Raul> Uh.. to the best of my knowledge, most packages which use these
> Raul> paths "hard code" them in some file.  Maybe you're suggesting
> Raul> that, if we adopt this convention, programs could start using
> Raul> this system (or something like it) at run time?
>
>	Really? I find I seldom have to use full path names for
> binaries (I expect ls, grep, et al to be in the PATH, as they
> should). I *NEVER* hard code the so called sbindir; and I think that
> scripts should not, precisely for this reason.

I interpreted Raul's comment as talking about binaries more than
scripts. Several programs I've packaged use --foodir=/bar as more than a
directive to the install phase. trn4 is a good example; it uses a
collection of auxiliary scripts called both by the main binary and by
users, and, in order to have it co-operate with other versions of trn
(which have some auxiliary scripts with the same names), the Configure
script sets explicit paths in config.sh. Other packages need to know the
location of their data directories. Not every path is an execution path.

>	I am quite certain that installing in /opt or installing in
> /some/path/that/I/control sohuld be a dpkg option, and certainly
> should not bleed over into package maintainer scripts.

dpkg relocation works only as long as no binary needs any knowledge of
paths, and is therefore necessarily a poor-cousin option that works only
for some portion of the packages currently in the archive. Making it
work for non-path-agnostic binaries requires non-trivial and kludgy
modifications to upstream source, which in turn makes Debian more
fragile. Even for scripts referring to data directories, having dpkg
somehow magically modify them is going to be broken.

configure-time relocation is right for these packages, and, since these
packages obviously have to have their files installed somewhere as well,
doing the job both at configure time and in dpkg will cause problems. At
best you need to have knowledge in individual packages about what needs
to be relocated, which brings you back to modifying large numbers of
packages.

By analogy with dpkg-architecture, I'd like to see the following idiom
in debian/rules, which has the extra advantage of avoiding the "include
this in both sh and make" thing and of only setting the make variables
that need to be set:

  BINDIR=$(shell dpkg-paths -qBINDIR)

  configure:
          ./configure --bindir=$(BINDIR)

-- 
Colin Watson                                     [cjw44@flatline.org.uk]



Reply to: