systemd / cross-building / failure in dpkg-gencontrol

[Michael Biebl]

Am 24.08.2015 um 08:21 schrieb Johannes Schauer:
> 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".

That, and the point that with mk-build-depends I can easily work from my
git checkout, where I usually don't have any .dsc, but only the debian/
directory.

>> 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.

It would be great if one of you can follow up on #794538 (or file a new
bug report against devscripts), since you obviously are in a much better
position to explain any details to the maintainer of mk-build-deps.

For the time being, I'm ok with installing the b-deps manually, so I'd
keep what we have in systemd.git if there is a plan to get this fixed
eventually.

Thank you both for the quick reply.

Cheers,
Michael




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150824/794340d8/attachment-0002.sig>