Hi all,
Quoting Helmut Grohne (2015-08-24 07:32:16)
> If I remember correctly, dpkg-gencontrol reduces architecture and
> profile restrictions, so these work by chance.
> It is not clear how to implement :native for mk-build-deps, because it does
> not differentiate between build architecture and host architecture. Maybe the
> simplest fix would be to s/:native// in mk-build-deps and declare cross
> support unfixably broken. Dima Kogan already observed that it does not work
> at all in #794538.
This is fixable. It has to be because building a binary package to satisfy
dependencies already works in other situations while still being cross-aware,
most notably in sbuild.
Namely, what mk-build-deps should do is to copy the sbuild behaviour:
- use libdpkg-perl to parse and process the Build-{Depends,Conflicts}* fields
and filter architecture and profile restrictions correctly
- change the meaning of its --arch option (this currently does some magic
depending on whether the source package has architecture specific build
dependencies or not):
- this option should specify the HOST architecture
- the generated binary package should be of this architecture (this is
already the case)
- foo:native dependencies should be converted to foo:$build
- the dependency on build-essential should be build-essential:$build
- if host != build, then an additional build dependency on
crossbuild-essential-$host:$build should be added
- change the created binary package name to have "cross" or a similar
identifier in its name so that it can be installed at the same time
with a package for a native build for the same source package
Doing all this is not very hard and the code even already exists in perl in the
function setup_apt_archive() in the sbuild source code at
lib/Sbuild/ResolverBase.pm:
http://sources.debian.net/src/sbuild/0.65.2-1.1/lib/Sbuild/ResolverBase.pm/#L692
> Actually, is there any use of mk-build-deps after experimental's apt has
> transitioned to unstable? It allows "apt-get build-dep foo.dsc" and "apt-get
> build-dep extracted-package". Just wondering.
Yes. mk-build-deps creates a meta package that is easily identifiable, so it
makes it easy to keep track of the list of source packages for which I
installed their build dependencies on my system, so that I can easily select
which ones I want to keep or remove.
I assume that the new "apt-get build-dep foo.dsc" code marks the newly
installed binaries as manually installed, so it is harder to remove them. With
mk-build-deps, only the meta package is marked as manually installed and the
rest can easily be removed by the removal of the meta package with "apt-get
autoremove".
> It is also unclear how to ever implement full build profile support into
> mk-build-deps. It seems that the generated package name should not only
> depend on B-D vs. B-D-I and the source package name, but also on selected
> profiles.
Yes. But right now, mk-build-deps doesn't even allow selecting any build
profiles, this is a separate feature request. Once it does it probably wants to
use libdpkg-perl and in that case it has to be careful also to read the
environment variable DEB_BUILD_PROFILES when it inserts the selected build
profiles into the output package name.
cheers, josch
Attachment:
signature.asc
Description: signature