Package: protobuf-c-compiler Version: 1.2.1-1 Tags: patch User: [email protected] Usertags: rebootstrap Control: affects -1 + src:collectd src:criu src:dnstap-ldns src:libgadu src:ocserv src:php-pinba src:riemann-c-client src:unbound
protobuf-c-compiler is a build tool that is quite similar to flex and bison in some aspects: You run it during a build and use the resulting C source code together with a library in your application. When cross compiling this means that you need a build architecture protobuf-c-compiler and the corresponding host architecture library. What currently happens in practise is that you get the host architecture protofbuf-c-compiler. Thus running it fails. Unfortunately, protobuf-c-compiler is something we need for bringing up new architectures. The dependency chain is wicked. login is essential and built from shadow. shadow Build-Depends on libaudit-dev, which is built from audit. audit Build-Depends on libprelude-dev, which is built from libprelude. libprelude Build-Depends on libgnutls28-dev, which is built from gnutls28. Since very recently gnutls28 Build-Depends on libunbound-dev, which is built from unbound. unbound Build-Depends on protobuf-c-compiler. See? Wicked. When resolving cross build dependencies, all dependencies are considered host architecture dependencies by default. Switching a chain from host architecture to build architecture is simple (e.g. M-A:foreign), but switching a chain from build to host is impossible. Marking protobuf-c-compiler Multi-Arch: foreign would thus enable us to execute it during cross builds, but it would also select libprotobuf-c-dev for the build architecture while users need libprotobuf-c-dev for the host architecture. The key here is to flip the dependency around (due to the aforementioned limitation). Rather than having packages build depend on the compiler, have them depend on the library and have the library depend on the compiler. There are a few basic approaches to implement the flip and they each have unique advantages and disadvantages. So let me explain them. * "have people depend on two packages" This will be used by e.g. flex. Packages that need both flex and the library will simply have to say "Build-Depends: flex, libfl-dev". Then they will get a build architecture flex and a host architecture libfl-dev. For protobuf-c this would amount to dropping the dependency from protobuf-c-compiler on libprotobuf-c-dev and then marking protobuf-c-compiler Multi-Arch: foreign. All of the 8 build-rdeps of protobuf-c-compiler already have a dependency on libprotobuf-c-dev or libprotobuf-c0-dev. Thus no changes are necessary in the build-rdeps. The approach is simple. I sent a similar patch for flex in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840080#16. * "swap the packages behind the scenes" Rename protobuf-c-compiler to something else (e.g. libprotobuf-c-bin), have it drop its dependency on libprotobuf-c-dev and mark it Multi-Arch: foreign. Then have libprotobuf-c-dev depend on libprotobuf-c-bin and provide protobuf-c-compiler. It sounds strange at first and needs to go through the NEW queue, but it makes it really hard to get Build-Depends wrong. I sent a similar patch for flex in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840080#5. * "dump the problem on users" Mark libprotobuf-c* Multi-Arch: same and request that rdeps use "Build-Depends: protobuf-c-compiler:native, libprotobuf-c-dev". This solution is even simpler from the protobuf side than the first, but incurs complexity in downstreams. Thus I don't like it. Given the low number (8) of build-rdeps I find both of the first two options reasonable. I'd appreciate if you could give an initial reply in a timely manner. I'll try to answer any open questions and work out a patch for the preferred approach. I'm also attaching a patch for the first approach, because it is so simple. It's kinda urgent now that gnutls28 3.5.6-3 pulled protobuf-c into the bootstrap set. :-/ Helmut
diff --minimal -Nru protobuf-c-1.2.1/debian/changelog protobuf-c-1.2.1/debian/changelog --- protobuf-c-1.2.1/debian/changelog 2016-02-02 23:42:33.000000000 +0100 +++ protobuf-c-1.2.1/debian/changelog 2016-11-24 09:26:34.000000000 +0100 @@ -1,3 +1,12 @@ +protobuf-c (1.2.1-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Mark libprotobuf-c* Multi-Arch: same. + * Drop the protobuf-c-compiler -> libprotobuf-c-dev dependency. + * Mark protobuf-c-compiler Multi-Arch: foreign (Closes: #-1). + + -- Helmut Grohne <[email protected]> Thu, 24 Nov 2016 09:26:34 +0100 + protobuf-c (1.2.1-1) unstable; urgency=medium * Imported Upstream version 1.2.0 diff --minimal -Nru protobuf-c-1.2.1/debian/control protobuf-c-1.2.1/debian/control --- protobuf-c-1.2.1/debian/control 2016-02-02 23:42:33.000000000 +0100 +++ protobuf-c-1.2.1/debian/control 2016-11-24 09:26:31.000000000 +0100 @@ -26,6 +26,7 @@ Conflicts: libprotobuf-c0-dev Replaces: libprotobuf-c0-dev Breaks: protobuf-c-compiler (<< 1.0.0~) +Multi-Arch: same Description: Protocol Buffers C static library and headers (protobuf-c) Protocol Buffers are a flexible, efficient, automated mechanism for serializing structured data - similar to XML, but smaller, faster, and @@ -43,6 +44,7 @@ Architecture: any Section: libs Depends: ${misc:Depends}, ${shlibs:Depends} +Multi-Arch: same Description: Protocol Buffers C shared library (protobuf-c) Protocol Buffers are a flexible, efficient, automated mechanism for serializing structured data - similar to XML, but smaller, faster, and @@ -61,6 +63,7 @@ Section: debug Priority: extra Depends: libprotobuf-c1 (= ${binary:Version}), ${misc:Depends} +Multi-Arch: same Description: Protocol Buffers C shared library debug symbols (protobuf-c) Protocol Buffers are a flexible, efficient, automated mechanism for serializing structured data - similar to XML, but smaller, faster, and @@ -77,9 +80,9 @@ Package: protobuf-c-compiler Architecture: any Depends: - libprotobuf-c-dev (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}, +Multi-Arch: foreign Description: Protocol Buffers C compiler (protobuf-c) Protocol Buffers are a flexible, efficient, automated mechanism for serializing structured data - similar to XML, but smaller, faster, and
