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

Re: afraid to build from source? (was Re: Remove cdrtools)

[Wouter Verhelst]
> It has nothing to do with "being afraid to", but everything with "not
> needing to".

There's lots of things we don't _need_ to do but we do anyway, as a
matter of quality of implementation.  I believe that building a package
from source is something we should do as well, if only to ensure that
our packages do continue to build from source, using our tools.  And
when I say "from source", I'm using the GPL definition of source code,
"the preferred form for making modificatons", which I think is a pretty
useful definition in general.

> Sure, you should verify that things still work if you run autoreconf
> on your source tarball, but there is no real need to build autotools
> output files in the build target of debian/rules if all you want to
> do is verify that they build properly.

The same could be said for lots of other tools: bison and flex are the
obvious ones, but also yodl, docbook2x and other documentation
convertors.  Is it reasonable to tell maintainers that every
architecture-independent generated file should be built manually and
shipped in the .diff.gz rather than built as part of the debian build?

> Moreover, this thread, at least to me, is more about what an upstream
> should do rather than what a Debian developer should do; it is not
> good practice as an upstream to assume that anyone else than yourself
> will need to run the autotools on your input files on a regular
> basis.

What an upstream should do and what Debian should do are quite
different things.  It has long been accepted that an upstream's best
practice is _not_ to require users to have autoconf installed locally -
they can assume you have a compiler and make and common tools like awk,
but not autoconf or flex.  Debian does not have this problem.  Our
'apt-get build-dep' command ensures that it is convenient for our users
to use pretty much any tool we need, when rebuilding our packages.  We
don't _have_ to worry about providing pre-built output from autoconf,
flex, bison and the like.  Our build dependencies even make it easy to
require a particular minimum version of any tool.

In summary, I think it's important for our users to be able to build
packages from source.  This implies that _we_ should build from source,
in order to exercise the whole toolchain, so that we know it always
works.  And if it's so fragile that it _doesn't_ always work ... well,
then _that's_ a problem which needs to be addressed.

Is the autoconf unreliability problem really so intractible that it
requires a workaround of "don't ever use it except in a manual process
where you can test it immediately to see if it worked"?  Would we
tolerate that same requirement in a tool like docbook2x?

Attachment: signature.asc
Description: Digital signature

Reply to: