Quoting Ben Hutchings (2017-07-17 02:17:12)
> However, I can see it has changed since I last looked and now says that
> "stage1" has been deprecated. I don't understand why this is or how we're
> supposed to give this hint to bootstrapping tools now.
When package maintainers implement build profiles, then this is mostly because
of bootstrapping reasons. So it was very tempting for them to just use a
"stage1" profile to disable feature XY. But this is not quite a clean way to go
about it. Build profiles are not only useful for bootstrapping. They can also
be useful for our downstreams who want to build packages without a certain
feature enabled. They can also be useful for Debian to become the base of
embedded systems where it is a bad idea to build all source packages with "all
features enabled" as it is usually done. To enable these use-cases it's a bad
idea to just use "stage1" as a catch-all build profile used to reduce build
dependencies. It is far more useful to use build profiles that document the
intention. This is done by the no${feature} profile names where ${feature}
currently are languages like java or python but can also be things like "doc",
"udeb" or "check". To also allow for experimentation, there are also package
specific profile names, namely pkg.$sourcepackage.$anything which allow source
package maintainers to add new conventions before they are moved into the
global build profile namespace. Descriptive profile names are far more useful
than just the "stage1" catchall and they also make the code much cleaner and
easier to understand its intention.
It is not intended to completely forbid the "stage1" profile name. It is clear
that it has its use for the initial cross-compiler bootstrap involving glibc,
gcc and linux. I'm not sure whether policy should completely forbid the usage
of build profile names that are not "officially listed". We don't forbid
DEB_BUILD_OPTIONS which are not in policy either. I'm not even sure whether
policy should explicitly mention the few packages for which stage1 is okay to
be used. For me, it's just important that the "stage1" and "stage2" profile
names are not abused by any package that wants to add build profiles to make it
easier to bootstrap Debian.
As for your last concern, the hint for bootstrapping tools: Whether dropping a
build dependency is to ease bootstrapping is nothing that a source package
maintainer should maintain. This is because the reason why dropping a build
dependency of a certain source package is relevant for bootstrapping or not is
not a function of the source package in question itself but instead is a
function of the package interdependencies at large. So if we wanted to have a
"stage1" profile which each source package maintainer should exclusively use
for bootstrapping purposes, then we would be in a constant cat-and-mouse game
where package maintainers would repeatedly have to change the build profiles
they implement because of how dependencies elsewhere in the archive change.
This is certainly not feasible. So instead of package maintainers annotating a
dropped build dependency with the information of "this is intended to ease
bootstrapping" by using the "stage1" profile, we instead let them annotate that
dependency with "this is intended to make the package build without Python".
For an algorithm it makes little difference whether the build profile which
drops the dependency on Python is named "stage1" or "nopython". The algorithm
knows that it's looking for a package that can be built without Python. For it,
it doesn't matter how the profile is named. For the algorithm, the source
package which can be built with a "nopython" profile is just another node in
the dependency graph that it can use to find the feedback-arc-set and make it
acyclic.
Thanks!
cheers, josch
Attachment:
signature.asc
Description: signature