Helmut Grohne wrote: > 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.
Hi, Helmut: Thanks for the detailed write-up in this bug report. I think I prefer your first solution the best, because if I understand the second solution correctly, it causes the libprotobuf-c-dev package to depend on the package which provides the protobuf-c compiler, and at least in theory the protobuf-c library has some functionality which is usable without the compiler. I will upload a new protobuf-c package with your patch shortly. Some comments on the dependency chain below. > 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. If this were the end of the dependency chain, then OK, we can upload a fixed protobuf-c and that's it. But it's not the end of the chain; protobuf-c build-depends on src:protobuf, and protobuf has a long history of being difficult to get building on all architectures at the same time (for instance, just have a look at the current buildd logs). Should we (Debian) look at how to get protobuf out of the dependency chain for bringing up new architectures? I'm at least partially responsible for this chain. Unbound build-depends on src:protobuf-c because of an optional feature which I turned on in the unbound build (--enable-dnstap) that requires protobuf-c. I also implemented changes in unbound (#828699) that allowed gnutls28 to build-depend on libunbound-dev for DANE support. Both of these are nice features to have and there are at least some users who would be disappointed if they were removed. Looking farther up the chain I see the audit → libprelude-dev build-dependency is due to --with-prelude being enabled in the audit build. Perhaps this feature could be targeted, similarly to #840262? I also wonder if the audisp-prelude plugin [0] could be split from src:audit and built by a separate source package. (It looks like the upstream developers prefer a monolithic repository, though.) [0] https://github.com/linux-audit/audit-userspace/tree/master/audisp/plugins/prelude -- Robert Edmonds [email protected]
