Hi Thorsten, On Tue, Aug 18, 2020 at 10:51:23PM +0200, Thorsten Glaser wrote: > That’s because I did a massive hack using versions of > Haskell from snapshot.d.o and some self-compiled intermediate > (read: old) versions to make pandoc installable-ish on x32. > I did the unspeakable there thus…
This is the bit I was somehow missing in the discussion. Thanks for your effort here. > This state will not last, and it’s unclear if it even works right. Yes. I don't think this is only a topic of bootstrapping. We actually don't bootstrap that often and requiring a bit of effort seems reasonable. It really is a topic of keeping the archive up to date with reasonable effort. If a package becomes bd-uninstallable repeatedly and requires this bootstrap-ish effort (per architecture), then something is wrong. It appears to me that this is the case here and this is what Adrian and Thorsten complain about. I also looked into https://bootstrap.debian.net/botch-native/amd64/stats.html and couldn't find a cycle there. Maybe we should remove the bootstrapping argument from the discussion? This is not black and white. We're ultimately talking about trade-offs. We're making this easier on one side and more difficult on the other or vice versa. What Adrian and Thorsten have proposed is the solution that makes it effortless on the side of keeping the archive up to date. (It still requires effort, but not necessarily with libmaxminddb.) The status quo is maximizing features at the expense of porter time. I think a key takeaway is that we will not have pandoc for all architectures. Getting it built everywhere is beyond our capacity as porters and package maintainers. It'll exist for release architectures, but not for all ports. The wisdom that you should only list pandoc in B-D-I certainly isn't new as a general rule of thumb and I think Thorsten explained again why we have it. Any solution where we still have pandoc in B-D-A, is a solution that requires some effort from porters. This is why Adrian and Thorsten push back here. They rightly do. For that reason, my nodoc proposal looks like a non-solution to me. It is something that Adrian has already done manually to work around the issue. I've also attempted to convert the manual pages using ronn and the output is rather unpleasant. So let's look at the costs for the solution where we split off manual pages. We'd add a binary package, yes. It contains two small manual pages. libmaxminddb-dev also contains 14 manpage links, that would likely move to the new package. This is still a small package, but the cost of a small package to the archive is relatively small. Let me give more examples where a technical matter resulted in a package split: * qt5-qmake -> qt5-qmake-bin was split for cross building. * libglib2.0-dev -> libglib2.0-dev-bin was split for cross building. * dropbear was split into dropbear-bin, dropbear-initramfs, dropbear-run to make the init and initramfs integration optional. * cryptsetup was similarly split. This really is a common thing. Putting the .service/init.d files in a different package is very similar to putting manual pages in a different package to me. I must admit that I find the trade-off proposed by Adrian and Thorsten quite reasonable. I've also looked for more options, but none came to my mind. Faidon, can you elaborate on the costs of the split from your point of view? It would seem quite cheap on the maintenance side to me. Helmut
