Re: Source-Depends? Autoreconf?
* Marius Vollmer <marius.vollmer@gmail.com> [090502 13:50]:
> Still, I feel that this area of what should and shouldn't be in a source
> package is a bit under-addressed in Debian. (That is very likely only my
> own ignorance. I learned the little I know about packaging in Maemo;
> apologies might be in order for me speaking up on this list... :)
First of all, you do not discuss the most common type of packages: do
not change the build-system, but just use it. This means autotools are
never called, neighter when preparing the package, nor when building the
package.
I assume you only speak about Debian source package that have to change
the build system, because I think using upstream's build system where it
is resonably possible is the best way to go.
> On one end of the spectrum, a Debian source package could try to have as
> little dependencies during build-time as possible.
The "as little dependencies as possible" part is only a very minor thing
to look for in packages, especially when talking about relatively small
things like autotools.
The more important goals are:
- derivation from upstream:
+ every change means using something not previously tested.
- verifiability/identification of changes
+ we want users to see what we changed so they know what they use
+ we want upstreams/other downstreams to see what we changed so they
can profit from out work
- maintainability
+ when it is to hard for a maintainer to do something, errors happen
more easily.
- robustness
+ the less chances for failing builds, the better
These goals contradict each other, and the trick is to find a good
compromise.
The first dogma Debian usually follows is shipping sources as an
pristine upstream tarball plus changes. As this only effects the form
of distribution, it does not change anything but representation of
changes (assuming there are good enough tools). And there is no way to
claim changes from upstream are better expressed than by starting with
the pristine tarball.
Now if you have changes in the build system to do, there are multiple
possibilities:
Change source files, run autoreconf, ship the result in .diff.gz:
- derivation: may use a different autotools version than upstream, but
that might be likely to be tested by others.
- identification: hard, as it is hard to see what is changed where
- maintainability: relatively easy
- robustness: good
Change source files, run autoreconf, ship the result in a seperate patch
- derivation: may use a different autotools version than upstream, but
that might be likely to be tested by others.
- identification: better, as the "automatic" changes are in a single diff
- maintainability: needs proper tools or scripts, but quite easy
- robustness: good
Change source files, change the generated files to what the changes with
the same autotools version would produce or otherwise minimal
- derivation: actual derivation my be smaller than before, but noone
else tests exactly that code.
- identification: most of the time even better to see what actually
changed, though one has be able to verify that the build system's
sources and generated files are modified the same way.
- maintainability: needs manual work, bad
- robustness: good
Change source files, run autoreconf at build time
- derivation: package is build with a system run with another autotools
version, but the way this is done is canonical
- identification: as only the build system's source file changes, easy
to grasp (unless the new autotools version bring the real changes).
- maintainability: perfect
- robustness: danger of new autotools version breaking the build
As you see, most of the pros and cons of each method depend massively
on what the actual changes are.
Also assessment of external factors plays an important role. Several
years ago, autotools changed quite rapdily and disruptively. Robustness
was an important reason to not run autotools while building.
Now this has changed, so running autotools at build time is often
considered the best solution, as it causes clean diffs, well-tested
build paths and easy maintanability. (Though it still depends on the
actual case. Very small changes, massively outdated uptreams and/or
usage of strange corner-cases of autotools can still make something else
better depending on a wide range of factors).
> This would be nice
> for distributions downstream of Debian that would have less trouble
> importing Debian source packages.
I do not think why this is "nice". If they do not change anything, it
does not matter much how the source builds. If they change anything,
every side could be argued to be more "nice".
Hochachtungsvoll,
Bernhard R. Link
Reply to: