Web lists-archives.com

Bootstrapping debhelper (was: Re: Do we want to Require or Recommend DH)

Quoting Sam Hartman (2019-05-13 21:49:20)
> >>>>> "Holger" == Holger Levsen <holger@xxxxxxxxxxxxxx> 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:


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


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:


And since recently we also have actual cross-builds of source packages that
satisfy their cross-build dependencies:


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. :)


cheers, josch

Attachment: signature.asc
Description: signature