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

Re: systemd / cross-building / failure in dpkg-gencontrol

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/

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

Thank you both for the quick reply.


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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: