On Sat, Nov 26, 2016 at 03:34:44PM -0500, Robert Edmonds wrote: > without the compiler. I will upload a new protobuf-c package with your > patch shortly.
Great! I'll look into how far I can get with it. > 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 completely agree. When I filed this bug, I overlooked the Build-Depends: libprotobuf-dev. Nevertheless, I think having protobuf-c-compiler work for cross compilation would still be useful for cross compiler end users. > 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. When I file patches for improving bootstrappability, I try hard not to regress on such nice features. I consider the existence of such chains as usual and try to work with them. > 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.) In general, splitting addon features to different source packages makes bootstrapping easier as the Build-Depends become more fine grained. Where feasible, I even prefer it to using build profiles. Nevertheless, dropping the audit -> libprelude dependency is not going to buy us much as other bootstrap components need gnutls28 as well. For instance apt uses curl, which uses gnutls82. If we want to go with a stage, then likely gnutls28 is the place to add it. I do note that staged builds have a significant maintenance cost. Keeping stages working is non-trivial. Ensuring that their output is compatible with unstaged builds is next to impossible. Thus I try to avoid staged builds as much as I can - to the point of considering larger dependency chains. Profiles such as <nopython> are slightly better, because we can leverage reproducible builds to validate them natively. Helmut
