Re: Modifying Debian for Infrastructures--Step 1
Dear Camm,
thanks a lot for your feedback. I'm lacking Debian packaging experience
(I'm a Debian user who read some manuals), so it is important that you
straighter out my ideas...
>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.
I agree that running sed in an automatic fashion is dangerous and that
intelligent treatment of the situation by the Debian maintainer would be
much superior.
This said, I would like to find a method that works for the general case
that works now. In a second, necessarily slower step, if it is possible to
learn from this experience and have some of it flow into Debian policy that
would make me very happy!
I believe that hardcoded path in source code is quite common--basically
every security conscious software will make it impossible to modify some of
its bahavior with an easily crackable configuration file. So this is why I
came up with the sed method that possibly works for any source language,
kind of make mechanism, etc. My reasoning is that the number of cases
where the dangers hit is smaller than the number of cases where one has
hardcoded path in the sources.
Maybe a solution would be to limit the automatic sed approach to the
makefile (in all its variants) and only grep on the sources in order to
detect hardcoding of path that cannot be controlled from the Makefile.
This is saver and probably quite general (although not totally automatic.).
My questions would be which Debian control files have path in it that have
to be changed...
Do you think that with the requirement of finding something general that
works now, some restrictions of the automatism and a more selective
handling of different kinds of files could make it less dangerous?
For a better idea of what file layout I have in mind for "Cluster Debian",
look at the figure at
http://www.sistema.it/twiki/bin/view/Main/DebInf3#Layout of Shared Network
Filesystem. You can tell that as compared to current practise, the layout
is modified due to two major requirements:
* multiple architectures that share certain things like doc
* multiple versions
I suppose the possibility to use muliple versions is very easy to sell to
beowulf people who roll their own scientific software...
An important point to note is that you don't simply move the whole root of
the package's tree to a different point, but you do different moves for
different subtrees (doc, bin, etc.).
I'd be very happy for feedback on this first layout idea for "Cluster
Debian". I'm sure improvements are possible...
For the longer term solution that would require a debian policy change, as
you said, all the path decisions could be parametrized with variables
instead of hardcoded. The actual values for these variables would be in
some control file that is used duing the building of the package.
The benefits I see in this include the following:
* packaging becomes independent of the choice of FHS
* this is probably a prerequisite for extending Debian to handle multiple
versions of a package on a single machine
* "Cluster Debian" uses the same packages as normal Debian (which avoids
to create yet another distribution and an even increased duplication of
effort for packaging).
* Debian packages could more easily and automatically be converted to other
package formats (rpm, solaris, etc.). This would likely boost the number
of contributed packages (there may still be some quality control and fine
tuning necessary to make it an official Debian package--but most of the
work is done).
Do you think such a policy change could find enough supporters? How would
one go about to propose it and how long would it take to implement?
looking forward to your feedback on this
--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 |
\------------------------------------------------------------------------/
Reply to: