On Tue, Aug 18, 2020 at 09:38:17PM +0300, Faidon Liambotis wrote: > I understand the overall problem and I do think that Debian being > bootstrappable is a worthy and meaningful goal for what it's worth!
Thank you. > I'm not sure whether the package not being a leaf has that much to do > with it. Honestly, I feel like blaming libmaxminddb for bootstrappability > issues is a bit odd. The chain I think is: > isc-dhcp-client(?) -> bind9 -> libmaxminddb -> pandoc -> <bunch of Haskell> > with Haskell being particularly hard to bootstrap. Did I get that right? The cycle seems wrong to me. isc-dhcp-client Build-Depends on libbind-export-dev, which is built from src:bind9-libs and doesn't depend on something built from libmaxminddb. So this particular cycle is already solved at the bind level by splitting the bind source package. This is not to say that there would be no cycle. I haven't checked, but it isn't this cycle. I also note that cycles involving pandoc doc not affect cross bootstrap in any way, because pandoc is marked Multi-Arch: foreign. Therefore, the problem at hand can only be about native bootstraps, which are pretty badly supported anyway. That said, if you want to break a cycle using cross compilation (which is not applicable to all bootstrap scenarios), libmaxminddb would have to be cross buildable, which presently isn't the case. This is due to all the perl-ish dependencies. Do I understand correctly, that you only need them for running unit tests? If yes, please annotate them <!nocheck>. > All that said, I don't want to be an obstacle here and would be happy to > help, as long as what we end up doing makes overall sense :) Speaking of sense: Having the libmaxminddb.3 manual page in the libmaxminddb0 packages certainly does not make sense. You added the developer documentation to the shared library package. A much better place would be libmaxminddb-dev. Unfortunately, that doesn't help us in any way with solving the bootstrapping problem at hand. > git-man has 171 manpages and is multiple megabytes in size. That's not > comparable in the slightest with libmaxminddb which 2 manpages that are > 10KB combined. I disagree that splitting off its two manpages into a > separate package is the reasonable thing to do here, I'm afraid. It actually is kinda worse here. The manual pages presently reside in different packages. Splitting them off would add two binary packages, not just one. Indeed this looks like quite a large hammer to me. So let's talk about alternatives. 1. nodoc. There is a build profile/option called nodoc. I really hate it, because it makes things unreproducible and I like things to be reproducible. However, making the manual pages optional via a nodoc profile certainly solves the bootstrap cycle. It's just inconvenient for the bootstrapper and requires manual work. I don't like it, but it really is a solution. 2. Try a different converter. ronn (written in ruby) is such a converter. I'm not sure whether ruby cycles with libmaxminddb in some other way. So maybe this is less about making bootstraps possible, but more about making bootstraps convenient (i.e. not requiring manual work). This is an important property as well, as we already need to fiddle with way too many aspects to make bootstrapping possible. In this case, autobuilding is stuck and manual work is required. Thorsten, can you tell more as to what precisely the problem is? I looked into https://buildd.debian.org/status/package.php?p=libmaxminddb. It doesn't look bd-uninstallable anywhere. Helmut
