On re-reading this message, it seems to have a harsh tone. Sorry about that,
that was not my intention. Also I don't want to start a flame-war or
anything, but I do want either me or "the others" (whoever that includes)
convinced about the proper way of packaging programs with autotools. Or else
I want to be convinced that that's not going to happen. ;-)
On Fri, Feb 03, 2006 at 12:16:08AM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 02 Feb 2006, Damyan Ivanov wrote:
> > Bas Wijnen wrote:
> > > Many problems solve themselves when you compile from source instead of
> > > using pre-built files. That is true for executables, it is true for
> > > Makefile.in and configure as well.
> >
> > QA team seem to disagree. See
> > http://sam.zoy.org/lectures/20050910-debian/img0.html
>
> So, yes, *do* build everything from source (i.e. bootstrap all autotools
> from known-good Debian packaged autotools). You just don't need to do it at
> dpkg-buildpackage time, you can also do it before that.
The slides mention a number of possible problems when packaging programs which
use the autotools. Every single one of them can be solved by running auto*
from debian/rules (this is also pointed out in the slides). Still they claim
that this is not a good idea, for the following reasons:
1 You will need to build-depend on the proper version of each tool
2 The clean rule will be a nightmare to write
3 It creates useless build-dependencies
4 Unless you really know what you are doing, you will simply get it wrong
In my opinion, none of them are valid:
1: What's the problem with build-depends? We have a Debian system, all those
things are available. Yes, you need the correct version, so? We have the
correct version. Pbuilder will scream at you when you got it wrong.
2: I've seen worse nightmares, but I agree that it would be a good idea if
automake would generate an "autoclean" target, cleaning up all the stuff
that they leave. Anyway, once you've written the clean rule, it's always
the same: rm -f configure config.guess config.sub libtool .... ; find .
-name Makefile.in -exec rm {} \;
Since writing the clean rule needs to be done only once, it is much easier
than rerunning the autotools before every release, as is suggested.
3: See 1
4: If you're going to get it wrong, then why don't you get it wrong when doing
it manually before building the package? Of course you need to know what
you are doing, if not then you should orphan the package.
Apart from these points, which I hope we now all agree on (although I fear
this isn't the case), there are some other things:
- All the positive effects of running them before building the package of
course apply when running them during package-build. (using the latest
version and so on.)
- The .diff.gz becomes readable (a big advantage IMO, I usually check the diff
before sending a package to my sponsor, to see if I didn't accidentily put
things in that don't belong there).
- It is impossible to accidentily forget to rerun the autotools.
In other words, it prevents mistakes in the packaging. This is a Good Thing.
And the only bad thing about it seems to be resource consumption on the
buildds. Compiling will cost more time, and the build-depends need to be
retrieved and unpacked as well. Personally I think that if this becomes a
problem, it should be solved by finding more resources, not by using
pre-compiled parts of the source. But this is really the only valid concern I
can think of.
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html
Attachment:
signature.asc
Description: Digital signature