(cc'ing the debian-cross list, but please let me know if there's a "right" place to discuss architecture bootstrapping.)
For a long time, src:perl has had some limited support for bootstrapping a new architecture without /usr/bin/perl. We've gone to quite some trouble to avoid needing perl to build perl as far as possible, including quite a few sed scripts and a 600-line monstrous debian/rules file so we don't need debhelper. However, things like dpkg-shlibdeps and dpkg-gencontrol which are required for building .deb packages are #!/usr/bin/perl scripts, so this is arguably somewhat ineffective. The temptation for doing away with all these complications and starting to use debhelper for src:perl too has come up every now and then. The last time was when we had to implement separate binNMU changelogs (#797106), and now we're looking at -dbgsym packages (#810327). As I understand it, the idea in the src:perl "bootstrapping support" is roughly that you can manually build a static perl binary, temporarily symlink it into /usr/bin/ and then go ahead building the package. See debian/checkperl and the top of debian/rules. Presumably any build dependencies depending on perl would complicate matters. Now, I haven't really ever tried this myself, and it may well have bitrotted. Clearly bootstrappers are managing somehow, though, given that new Debian architectures seem to be popping up yearly or so. I wonder if the above process is actually used anywhere, or if people are doing something totally different to get working perl binary packages together? So if we started to build-depend on debhelper and therefore transitively perl, would anybody actually care? I note that recent progress on src:perl cross build support has promise in this area and might well be the final solution. However, it's new enough that I wouldn't really want to count on it quite yet. Thoughts? -- Niko Tyni nt...@debian.org
