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

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: