Hi Andreas, On Sun, Apr 27, 2025 at 04:20:37PM +0200, Andreas Metzler wrote: > just to doublecheck that I have the gist of it: You propose to add a > pkg.gnupg2.gpgvonly build-profile because > - gnupg2 breaks bootstrapping, deps are huge.
Allow me to add precision here. gnupg2 is part of the package set for building build-essential. It used to be fully cross buildable with what we could build there, but the recent addition of libtss-dev poses a problem, because tpm2-tss build-depends on libftdi1-dev (all other dependency can be cross built in the bootstrap setting) and libftdi1 requires libboost-dev for building, which at which point the dependency closure explodes. > - You only need gpgv for bootstrapping. Correct. > - It is beneficial to have a minimal profile instead of of profile that > only throws out the most problematic part (tss) because the less > required deps the component (gnupg) has the simpler bootstrapping > gets. Let me also add detail here. It is preferrable to have packages be buildable without any build profiles, because then automatic ordering is possible. gnupg2 was ordered automatically until it started depending on libtss-dev. It has now become evident that we need some build profile in some package to cut down dependency chains. Once we have a need for a build profile, it is preferable to cut down as much as possible from a bootstrapping pov as the goal is to use as few profiles as possible. You may still prefer to have a profile disabling tpm2daemon as a package maintainer and your preference for such a profile would likely bear more weight than the bootstrapper's preference for a minimal profile. We may also figure a way to add a profile to a different package instead of gnupg2. I tried to add it to libftdi1 first, but that does not look promising now. > Regarding the patch: Personally I do not like the debian/rules changes. > The file alread is Byzantine and this adds another 4 ifdefs. How about > changing this to > #ifdef > normal build > #else > gpgv-only > #endif > > Proposed diff (for 2.4.7-16) attached. (I have looked over the buildlogs > for your variant and this one and did not see a significant difference.) I think you missed attaching a diff. Generally, I am not opposed to implementing in such a way. It took me quite a while to arrive at a way that would work at all and I ended up not polishing it beyond that point. Evidently, it served as a starting point for discussion. Helmut
