Quoting Sam Hartman (2019-05-13 21:49:20) > >>>>> "Holger" == Holger Levsen <holger@layer-acht.org> writes: > Holger> On Mon, May 13, 2019 at 03:37:55PM -0400, Sam Hartman wrote: > Bernd> gcc also needs a compiler to build - so I think it should be > Bernd> safe to allow debhelper to build its package using > Bernd> debhelper. Or am I missing something here? > >> If we reach consensus on the overall idea, I was planning to ask > >> the debhelper maintainers whether they thought they needed an > >> exception for build-depends of debhelper. Unless you think you > >> have special knowledge there, let's assume we can handle that > >> question as part of working through details. > > Holger> I think being bootstrappable(.org) is a very worthwhile > Holger> feature, so please let's not make this harder than it > Holger> already is. > > Debhelper is arch all and because of its implementation its "opaque" > binaries aren't very opaque as these things go. > I think that the debhelper maintainers are aware of the issues of > bootstrappability and can make an informed decision here. Funnily, we just talked about Architecture:all packages in the bootstrapping context in #debian-bootstrap today with debhelper maintainers. Take away message: A binary package being Architecture:all doesn't remove it from the bootstrap problem because that package also has to be installable i.e: all its transitive Depends must exist as well and those may be Architecture:any, as is also the case for debhelper. So applying this "exception" to the build-depends on debhelper would not be enough. It would also have to be extended to the transitive build dependencies of binaries in the installation sets of those. Unfortunately, if you would indeed traverse the dependency graph in that way you will quickly end up with a strongly connected component of several thousand source packages in it: https://bootstrap.debian.net/history.html Fortunately, this is not really a problem (see below). > I'll be shocked if there's not already a cycle involving building dpkg > requiring a build of debhelper as an example. I can even show you cycles involving dpkg and Haskell, OCaml, Python, Xorg and ruby: https://bootstrap.debian.net/essential.html But all of this is hardly a problem in practice because much of the problem can be worked around by cross-building many of the involved packages before building packages natively. Of course (due to dependency cycles) not all source packages can be cross compiled even if it would technically be possible to do so, given the full archive. So all of this depends on the initial cross-bootstrap phase. Great progress is being made by the rebootstrap project: https://wiki.debian.org/HelmutGrohne/rebootstrap And since recently we also have actual cross-builds of source packages that satisfy their cross-build dependencies: http://crossqa.debian.net/ Long story short: "exception for build-depends on debhelper" as outlined above is not the right way forward to make debhelper bootstrappable. The correct solution is a bit more involved and (due to the prevalence of debhelper) probably involves making debhelper (and its installation set) be part of the cross-bootstrap. But debhelper maintainers are already lurking in #debian-bootstrap so I guess this topic is already covered. :) Thanks! cheers, josch
Attachment:
signature.asc
Description: signature