Rob Browning <rlb@cs.utexas.edu> writes: > I don't believe that debhelper address one of Ian's main complaints at > all. If I remeber correctly, that complaint was that when you use > debmake (or debhelper), you end up with debian package source with > non-deterministic behavior. Depending on the version of the packaging > tool installed on the system you use to build the package, you may get > a radically different resulting set of binaries. But using another compiler or dpkg would result in a different set of binaries, too. To get rid of the problems we need source depends. > In addition (but less important), the current approach requires that > you have the packaging tool package (debmake or debhelper) installed > on the system where you're doing the build. the only solution is to integrate the things into dpkg ... > Ian was proposing to fix these problems with a more > automake/autoconfish apprach where the commands to build your package > would reside within the package itself (rather than in /usr/bin via an > external package), and there would be a higher level command (like > autoconf) that when run would bring these embedded commands up to the > current packaging tool standards. it's nice to have, but brings no advantages. If we change the autoconfish thing we get the same different binaries as through changing debhelper/debmake. It's IMHO only a different view but no substantial change. And debhelper is working NOW - the other approach is vaporware. A solution can be to use autoconf for the architecture specific things and let the rest do from dpkg. Bye Christian -- Christian Leutloff, Aachen, Germany leutloff@sundancer.oche.de http://www.oche.de/~leutloff/ Debian GNU/Linux 1.3.1! Mehr unter http://www.de.debian.org/
Attachment:
pgp6keteORDaB.pgp
Description: PGP signature