Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
> The build bot people have a partial solution of their own. Yet, we
> still don't have a general way of specifying these dependencies in
> our packages.
Yep, and I agree that we should have such a thing. The "partial
solution" you mention is a (complete) central database of source
dependencies, and that was the only way to make the system going. If I
would have waited for every package coming with appropriate src-deps,
we wouldn't have a buildd system yet...
> My proposal is, in short, the following: Define six new fields for
> debian/control and specify their meaning. The six new fields are used
> only in .dsc files and in the first paragraph of debian/control. They
> are:
> * Depends
> Specifies the packages that must be installed when one of
> the targets build, binary, binary-arch and binary-indep
> of debian/rules is invoked.
> * Arch-Depends
> This is a variant of Depends which is followed only when
> the architecture-dependent parts of the package are being
> built.
> * Indep-Depends
> This is a variant of Depends which is followed only when
> the architecture-independent parts of the package are being
> built.
> * Conflicts, Arch-Conflicts, Indep-Conflicts
> These are analoguous to the dependency fields above.
This looks fine so far.
Just one note: Arch-{Depends,Conflicts} might be unnecessary, as it
should be very rare that someone only builds the arch-indep packages.
So we could merge Arch-Depends into Depends. If one compiles with
dpkg-buildpackage -B, he needs to look only at Depends.
dpkg-buildpackage without -B needs to look at Depends + Indep-Depends.
> It will not be necessary to specify "Essential: yes" or "Priority:
> required" packages, nor is it necessary to specify a minimal
> standard C and C++ compilation environment. The dpkg-dev package is
> also assumed to be installed. Helper packages such as debhelper, if
> any, *must* be specified.
For my current system I have defined the following packages as
build-essential:
- gcc
- g++
- binutils
- make
- fileutils
- shellutils
- libc6-dev
- libstdc++*-dev (current version)
- texinfo (really many packages need makeinfo from it)
- perl-5.005
- dpkg, dpkg-dev
- debhelper, debmake
The differences to your proposal are:
- texinfo is only Priority: standard, but it's really needed by lots
of packages (for makeinfo). I'm just too lazy to add tons of texinfo
src-dependencies...
- perl-5.005: only perl-base is essential; but the whole buildd
system is written in Perl itself, so it has to be installed anyway,
and it would be wasting bytes to mention it explicitly. But it
could make sense to mention perl in per-package src-deps.
- debhelper, debmake: used by so many packages again... and again, it
would make sense to mention them in per-packages dependencies.
> It needs a central repository of dependency information, and the way
> to inform that repository of changes in packaging is not well known.
So let's make it known here now :-) The sources of the src-deps are in
a CVS repository on :pserver:cvs.linux-m68k.org:/CVS, module name
srcdep. Anonymous read access is possible, and currently all buildd
admins have write access. But I don't want to give write access to a
broad public (e.g. all Debian developers), as some knowledge is needed
how the system works to modify the sources properly. And bad
modifications can easily make a lot of things fail for the build
daemons...
> This proposal does not deal with the fact that some packages need to
> have particular *source* packages unpacked and even perhaps
> partially built at the time of a build. Those issues are more
> complex and requires more study - perhaps the sbuild folks who have
> dealt with them can offer a solution?
My current src-deps have a solution, but it's more a hack than a
solution... sbuild knows so-called "special dependencies" that are no
packages to be installed but are defined themselves in the src-dep
file. Special deps can execute shell scripts before and/or after the
build, and can apply patches under conditions. And in such a shell
script, you can unpack some other package and e.g. configure it.
But for per-package src-deps we would need a better mechanism, of
course. What about the following: We additionally have a
Depends-Sourcetree: field that lists packages that are expected
unpacked. An entry there can be augmented by shell commands:
Depends-Sourcetree: tcl8.0 ("ln -s tcl8.0-* tcl8.0; cd tcl8.0; ./configure --prefix=/usr")
The source package for package tcl8.0 will be unpacked (with
dpkg-source -sn -x) in the directory where also the build dir for the
current package is. If shell commands are given in parens, they're
executed in a subshell.
Maybe hackery, too, but requiring unpacked and configured source trees
isn't nice, too :-(
Some other notes to your proposal: I would like to be more specific on
what can specified as a source dependency. Suggestions:
- The source dependencies can be specified the same way as normal
(binary) dependencies, i.e. you can depend on virtual packages,
alternatives, and you can specify version relations.
(BTW, sbuild can handle virtual packages (by installing a package
that is said to provide what's needed, or if nothing is configured
for this virtual pkg, an arbitrary provider. sbuild of course also
knows about version relations, but it currently can't downgrade
installed packages. sbuild *cannot* deal with alternatives.)
- You don't need to specify packages that are dependencies of another
package that is already a source dependency, provided that nothing
is used explicitly from the first package.
For example, if your package needs sharutils for uudecode,
sharutils depends on debianutils. But you don't need to mention
debianutils in the src-deps, except your package calls binaries
from debianutils explicitly, e.g. tempfile.
Rationale: Mentioning all binary dependencies of a needed package A
is simply unnecessary, apt-get or a similar tools can easily
determine what's additionally needed so that A can be installed.
However, binary dependencies of A can change, so if sharutils won't
depend on debianutils anymore some time in the future, your
src-deps would become incorrect by this external event if your
package uses tempfile.
This requirement specially also applies to shlib packages: You
usually source-depend on the -dev package, which binary-depends on
the shlib packages it needs.
- If a dependency on a -dev package is given, it must be a versioned
dependency if needed to ensure that the resulting (binary)
dependencies of built packages are unchanged.
Example: Package foo needs libbar1-dev. The shlibs file in libbar1
adds a binary dep "libbar1 (>= 1.1)" to foo. The src-dep on
libbar1-dev must be so that all versions of libbar1[-dev] it allows
will generate the same binary dep "libbar1 (>= 1.1)" (i.e., the
shlibs files are identical.)
This condition ensures that binary dependencies are correct if a
package is rebuilt (probably for another architecture). (And, BTW,
the current way to build the central src-dep db does this already,
too.)
Especially the last point can be a bit critical: A maintainer can
easily forget to update the version requirement of a -dev package, and
then results of recompiling this package can be wrong. That's why I
think parts of the src-deps should be generated automatically, to free
the maintainer of this burden and to avoid errors.
However, I see that this isn't easily implemented and will further
delay src-deps in policy. But without the requirement, the per-package
src-deps are a great deal less useful for the autobuilders :-(
Roman
Reply to: