Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Antti-Juhani Kaijanaho writes ("Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages"):
> I have re-read the discussion, and I think some points raised are valid.
> I'm hereby changing my proposal.
>
> The proposal has been seconded by Edward Betts <edward@debian.org>.
> I need his support for these changes, or a second from someone else.
> And I'm still looking for another second.
I strongly agree with the proposal. If you still need seconds, count
me as one.
> Summary of the changes:
> - The fields change as follows:
> Depends -> Build-Depends
> Arch-Depends (removed as suggested by Roman Hodek)
> Indep-Depends -> Build-Indep-Depends
> Conflicts -> Build-Conflicts
> Arch-Conflicts (removed as suggested by Roman Hodek)
> Indep-Conflicts -> Build-Indep-Conflicts
> (The rename suggested by Steve Greenland)
I agree with the prefix `Build-'.
I disagree with Roman's suggestion that we should remove the Arch-
versions because they'd not be used often. I think it important that
the resulting scheme be orthogonal. It should also parallel the
`binary-*' targets in debian/rules.
I therefore suggest the following list
Build-Depends
Build-Depends-Indep
Build-Depends-Arch
Build-Conflicts
Build-Conflicts-Indep
Build-Conflicts-Arch
where debian/rules binary-foo (where foo is indep or arch) requires
both the -Foo and plain Depends and Conflicts forms to be satisfied,
and debian/rules binary requires all six to be satisfied.
> - The syntax of the fields is explicitly mentioned to be
> identical to binary Depends et al. Mentioning redundant
> packages is explicitly discouraged. Strict versioning
> for -dev packages must be used.
> (Suggested by Roman Hodek.)
Right.
> The following suggestions will NOT be part of this proposal. They may
> be proposed separately if necessary.
>
> - Dependencies to source packages will not be supported.
> The only solution offered would break the declarative
> semantics of the control files, making them partly
> imperative. This is bad, because you would not be able
> to write both dependency *testers* and dependency *satisfiers*
> based on the suggested dependency information. (Satisfier
> meaning an apt-like entity which installs required packages
> and symlinks.)
> (Suggestion by Roman Hodek.)
Right.
> - Per-binary build-time dependencies will not be supported.
> There is no way to control the Debian build system
> in per-package basis, so per-package build-time dependencies
> would serve no useful purpose while, as noted by Roman Hodek,
> they do make parsing the dependencies harder.
> (Suggestion by Joey Hess.)
Right.
> - The current list of build-essential packages will not be
> included as a footnote to the Policy Manual. Try to
> generate it yourself and you shall understand why -
> it would way too long.
> (Suggestion by Santiago Vila.)
I think that instead the formulation about `compile and link a trivial
C or C++ program and put it in a Debian package' should be the
defining one. We can supply a list of example packages, but we should
explicitly state that it's only an example which was `true at the time
of writing'.
I think that texinfo shouldn't be there.
Can I suggest another couple of changes ?
Build-time dependencies must specify version number(s) of package(s)
if the version in the current Debian stable distribution is not
adequate. If this is necessary usually a >= dependency should be
used.
It is a bug if, after unpacking the source package on a system
running the current stable distribution, and satisfying the source
dependencies (including the implied dependencies), you cannot build
the package and produce a working binary package suitable for
installation into the binary distribution corresponding to the source
distribution which contained the source package.
Ian.
Reply to: