Hello, Johannes Schauer <josch@debian.org> (2015-05-29): > If one wants to build build-essential from scratch without relying on > packages from the archive (bootstrap scenario) then one has to > recursively build its build dependencies, the build dependencies of > these, and so on and so forth. The set of source package one then > ends up with is currently at least 818 source packages big for Debian > unstable amd64. I say "at least" because A|B type dependencies and > "Provides:" relationships allow different selections to satisfy > dependencies. The maximum number is 1135 source packages. > > src:libdebian-installer is in the smaller set. So it is *not* optional > by choosing a different alternative or Provides. It is also required > whether or not one relies on existing Architecture:all packages or > not. You can see a list of all source packages in the transitively > build-essential set here: > > http://bootstrap.debian.net/essential.html > > That page does not yet provide an explanation which dependency path > makes them being included because I didn't yet have the time to > generate this information. But for src:libdebian-installer, the > reason is, that it is in the strong dependency set of src:cdebconf > which in turn is needed by build-essential because of > libdebconfclient0 which is needed by base-passwd. Thanks for the dependency chain explanation. That kind of information will really be valuable to have extracted in an automated fashion. > > > [1] https://wiki.debian.org/BuildProfileSpec > > > > How stable is this spec, > > the syntax itself was set in stone (in the wiki page) at 2014-08-31 (which was > during the bootstrap sprint in paris) together with guillem who encoded this in > dpkg. All changes you see to that spec after this date are either > > - rewording to make hard to understand parts easier to read > > - add examples > > - expand the table of software that implements the syntax > > - adding new ideas of scenarios build profiles can be used in > > As the main author of the spec I'd say that the only things that could possibly > be changed during this release cycle are the amount of permissible build > profile names (if the need for a new one comes up). This would not affect the > patch submitted by Helmut in this bug because the "nocheck" build profile name > was always needed and part of the spec. > > The spec staying stable in its core (the syntax and fields) is furthermore > enforced by the fact that if something were to change now, then it would delay > the possibility of uploading packages with build profiles again until after the > release of Stretch in ~2 years. And we really don't want that :) > > So there is no plan to touch this thing in any other way than making things > more clear in places where it was not. Well, I hope it's more stable than the last time I saw people try and push stuff past release people and insist on having stuff deployed on Debian infra… until it was figured out that woops some changes were needed. I suppose having support merged into dpkg improves chances for that to no longer happen. > The syntax is not policy yet (bug #757760) but I'd compare this situation to > Multi-Arch which is also not policy yet but also has always only existed as a > wiki page and still is widely used in the archive. I plan to help getting build > profiles into policy during this release cycle. Drawing parallels with multi-arch isn't likely going to reassure people. Quite the contrary. ;p > > and how much is that syntax supported by Debian's tools > > You can see an overview of tool support for the build profile syntax in the > table at the top of the spec: > > https://wiki.debian.org/BuildProfileSpec > > Most notably, build profile support is missing in pbuilder until somebody > applies the latest patch which fixes that situation in bug #740577. Until then > one should either build without a chroot or use sbuild. > > >/infra? > > It's hard to test our infrastructure before things get deployed but luckily > another package using the build profile syntax in its Build-Depends has been > uploaded recently: gem2deb. That helped us spot some remaining bits which did > not support the new syntax (#786400 and #787093) but as you can see, the former > is fixed and the latter has a working patch and since I'm in contact with > Antonio I think it will be applied quickly. Yeah, I noticed the dd@ thread a little bit after replying. I think it'd be safer to wait a bit until the dust settles before applying this kind of patches in d-i packages. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature