Re: Modifying Debian for Infrastructures--Step 1
Greetings!
"Bud P. Bruegger" <bud@sistema.it> writes:
> For installing packages on a cluster of machines, we chose to install
> to a globally visible filesystem. There are directory subtrees for
> different versions of the same package and for different
> architectures. The individual machines use sym-link farms (created
> with slink or stow) to run these packages. In a first step we would
> like to modify source packages such that the installation directories
> become parametrized and choosable at build time as a command line
> option.
>
> Our current ideas are:
>
> o The debian source package already standardized what goes where.
>
> o Different versions of Debian may have different layouts--but
> that's predictable.
>
> o We believe that using SED or similar to substitute all
> /usr/bin, /etc, /usr/doc/, etc with some kind of a variable
> would be the right approach. This makes it irrelevant
> whether a certain path is coded in Makefile, a Makefile.in,
> a c source file, or whatever else.
>
Personally, I think that altering the upstream files with sed in an
automatic fashion is quite dangerous. The Debian package maintainer
has already done the hard work of adapting the wide variety of
upstream installation schemes to a process that puts files in a well
defined location. My recommendation is to add a rule in debian/rules
which runs after the 'install' rule, examines what files are in
debian/tmp et. al., and then builds modified trees as necessary under
debian/whatever. You could of course run a 'for i in $(find
debian/tmp -type f); do j=$(echo $i | sed 's,foo,bar,g'); cp -p $i $j;
done' or something like that in this rule if you'd like.
This then would only leave the relatively small number of cases (such
as lam) where the upstream source has hard-coded the destination path
of the binaries into the C source, or some such. In such a case, the
package manager has already had to deal with this, and I think we
should lever the solution that (s)he has come up with. The most
proper way (that I can think of, at any rate) of dealing with this is
with a configure variable, which would be called in debian/rules under
the 'build' target as 'configure --with-final-home=path' or some such
-- if Debian policy could standardize this, then all that remains is a
simple substitution of 'path' in debian/rules with a Makefile variable
specified on the command line.
Just my $0.02 :-)!
> o The only caveat we could think off was quoted slashes
> "\/usr\/bin" and path that are constructed from multiple
> variables. The former case could possibly be automated; we
> don't see a solution for the latter.
>
> o We write a simple wrapper around the build tool that adds a first
> step that substitutes all the above variables to the path
> specified on the command line.
>
> We would greatly appreciate any help with the following questions:
>
> o will this approach work? Is there something we didn't think of?
>
> o which are the path that have to be substituted? Where is the
> Debian doc that lists them all?
>
> Many thanks
>
> -- bud
>
>
> /------------------------------------------------------------------------\
> | Bud P. Bruegger, Ph.D. | mailto:bud@sistema.it |
> | Sistema | http://www.sistema.it |
> | Information Systems | voice general: +39-0564-418667 |
> | Via U. Bassi, 54 | voice direct: +39-0564-418667 (internal 41)|
> | 58100 Grosseto | fax: +39-0564-426104 |
> | Italy | P.Iva: 01116600535 |
> \------------------------------------------------------------------------/
>
>
> --
> To UNSUBSCRIBE, email to debian-beowulf-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Take care,
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: