Thoughts about src-dep implementation
Here are some thoughts how source dependencies can be reasonbly
implemented for now, and kind of a vision for the future:
- dpkg-source extracts the Build-* fields from the .dsc and writes
them to debian/build-depends.
This is necessary, as the actual checking is done before building,
and at this time the .dsc file isn't available anymore (at least
dpkg-buildpackage cannot know where it should look for it).
Simply using the Build-* fields in debian/control doesn't work if
the control file is built dynamically (as some packages do from a
control.in), or if the fields in control contain substitutions (see
below).
The fields in the .dsc file still are valuable for dependency
checking before unpacking.
- We extract some parts from sbuild and make a new script
dpkg-check-srcdeps from them. dpkg-buildpackage can call this
script if this is requested (or not inhibited), and can abort if
there are any errors. Also sbuild will use dpkg-check-srcdeps so
that the code isn't doubled.
Idea of the interface: input via options, output on stdout:
src/foo-1.2$ dpkg-check-srcdeps --build-depends='libbar1 (>= 2.0), libbaz2 (>= 1.0), bison, flex' --build-conflicts='termcap-compat, evil-pkg'
U libbar1:
I flex
R termcap-compat
src/foo-1.2$ dpkg-check-srcdeps -v --build-depends='libbar1 (>= 2.0), libbaz2 (>= 1.0), bison, flex' --build-conflicts='termcap-compat, evil-pkg'
C libbar1: non-matching version installed (1.9 ! >= 2.0)
C libbaz2: already installed (in sufficient version 1.0.1 >= 1.0)
C bison: already installed
C flex: missing
C termcap-compat: installed (negative dependency)
C evil-pkg: already deinstalled
U libbar1:
I flex
R termcap-compat
(I = install, U = upgrade, D = downgrade, R = remove, C = comment)
This is essentially which sbuild currently does. If sbuild will use
the external script, it just has to parse the output, but the
installation of packages etc. stays the same.
Until all packages come with src-deps, it's still necessary that
the checker script is able to read /etc/source-dependencies
(representing the current central database), but this can be a
seperate option used only by sbuild. I think we'll also need some
kind of override file, but this, too, can be an option.
- IMHO it's still a goal that parts of the source dependencies should
be auto-generated, for two reasons: 1) it saves some work for the
maintainer (he doesn't have to write down lots of -dev packages),
and 2) will avoid lots of errors. If we don't have that
auto-generation, it will be easy to forget that one has upgraded
some lib+dev packages, and therefore src-deps might have to change.
As you know, auto-generetable src-deps means mapping the shlibs in
binary deps to -dev package dependencies. We already have a
well-working mechanism to map shared libraries (their sonames) to
(binary) dependencies: the shlibs file. Something similar is needed
for src-deps then, too.
What we need is an answer to the question: What -dev package(s) in
which version are needed to compile this thing if it's linked with
libfoo.so.x? So we need a file that maps sonames (like the shlibs
file) to -dev package dependencies. Let me call this file "devdeps"
here, the name isn't important.
The devdeps is provided by the maintainer of the shlib package,
just like the shlibs. The reason for this is that this maintainer
usually better knows what versions are compatible and thus is
better responsible for deciding which version relations to use
(same argument as for shlibs).
If we now have such a devdeps file, dpkg-shlibdeps can generate in
the same run an entry build:Depends in the substvars file, and this
can be substituted in the Build-* fields of the control file. It's
not much additional work for dpkg-shlibdeps, as finding the
providing package is the same, it just has to look into a second
file and do the same lookup as for shlibs again.
The problem with this: Currently the .dsc is built before
compiling, and thus the Build-* fields have to be known before
dpkg-shlibdeps is run. But there's an easy solution (IMHO): Why
don't we build the source package after the binaries? This would
speed up the development cycle anyway, because as long as you're
experimenting you currently often build the src package
unnecessarily. Also, you automatically have cleaned source trees
after dpkg-buildpackage, which can save some disk space if you
maintain lots of packages :-) At least I can't see now big problems
if dpkg-buildpackage runs "debian/rules clean; dpkg-source -b"
after building the binaries. Comments?
Ok, what do you all think about this blurb? The auto-generation surely
is a topic for the future and not immediately needed.
Roman
Reply to: