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

Source-Depends? Autoreconf?



Hi,

here is some ghost spooking around in my head, and maybe you can help me
put it to rest.

The GNU build system makes a distinction between maintainers of a
source package and the people who eventually install it.  Essentially,
GNU is producing a source distribution that is aiming for very high
portability and ease of installation from source.

Because of that, the source packages produced by GNU projects are 'fat':
they contain the well-known biggish autotools build machinery, and they
even had a formal 'maintainer mode' concept.  That mode is falling out
of favor (because it is not doing its job in the best possible way), but
the release tarballs are still carefully constructed to need much fewer
external software than the maintainers need when creating that release
tarball.

Debian is much less concered about this distinction: for example, there
is no "dist" or "source" target in debian/rules, and no "Source-Depends"
or "Release-Depends" field that would state the required packages for
running it.

Making a Debian source package always felt cumbersome: dpkg-source just
tars up everything in front of it (I exaggerate, of course), and at
least I am not used to having to clean my source tree before making a
distribution tarball out of it.

Of course, Debian doesn't really need to be as careful about making
release tarballs as the GNU project: a Debian source package only needs
to work in Debian, and there is no need to include pre-built
documentation in the source, for example, because the tools to build it
are always there.

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... :)

On one end of the spectrum, a Debian source package could try to have as
little dependencies during build-time as possible.  This would be nice
for distributions downstream of Debian that would have less trouble
importing Debian source packages.  In this case, I think we would need
something like Source-Depends and making a source package would consist
of running the equivalent of "make maintainer-clean && autoreconf".

(If a downstream distribution wants to make changes to the source
packages that it imports from Debian, it can create the changed source
packages in Debian itself.  Ideally, there shouldn't ever be a need to
create a source package in such a--by choice--anemic downstream
distribution.)

On the other end of the spectrum, a source package would only contain
genuine sources; it wouldn't contain anything that can be regenerated
from other files in the source package.  For the typical package made
from a GNU upstream, this would mean always running autoreconf before
configure, for example.

I have the feeling that most Debian packages are somewhere in the
middle, without having any real opinion about where to go: they contain
lots of generated files, but there is no formal, uniform means to
regenerate them.  Also, no second thought is given to adding monster
toolchains like gtk-doc-tools to Build-Depends.


I think the first end of the spectrum is more flexible, and adding the
necessary bits to Debian (such as a "source" target in debian/rules)
would allow Debian to become a lot stronger as a repository of source
packages.  This added strength would mostly help the people lifting code
from Debian, of course, but I think Debian itself would also benefit
from it.

For example, Debian's 'lesser' architectures might have an easier time
with reduced build-dependencies, and it might even be possible to
formally allow 'cross' architectures into Debian: those architectures
would not be as general as the big ones and all packages for them would
be cross-compiled, perhaps.  (Reducing build-dependencies of source
packages goes a long way towards cross-compilability.)

Also, being more careful about source packages can help with keeping
things in VCS.  The new formalism for creating source packages can make
it easier to create them automatically from a 'bare' CVS branch that
doesn't contain any generated files.

That is actually what got me started thinking about this in the first
place: I want to keep my sources (both upstream and packaged) in a VCS
without any generated files; I want to automatically create source
packages of a bare branch in a rich environment; and I want to
automatically compile these source packages in a poor environment (that
doesn't have all the tools I use during development).

So, what do you think?


Reply to: