On Tue, 18 Jul 2017 at 09:06:23 +0200, Johannes Schauer wrote:
> 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 suspect stage1 might also still be useful for (possibly pre-emptively)
breaking cycles involving build-time vs. runtime dependencies, like the one
that historically existed between glib2.0 and dbus: it seems more
straightforward to have one profile name than to invent a series of
nodbus, noglib, noqt, etc. if each one will only be used in practice in
a small number of places to break cycles.
(dbus could likely avoid being involved in cycles without stage1 if there
was a notests profile - nocheck seems too narrow, since it's about
build-time tests and is not allowed to disable the dbus-tests binary
package that is used for as-installed testing.)
Profiles like nocheck and nopython make a lot of sense as a way for
derivatives (or maintainers wanting a test-build in a hurry) to prune
dependencies, but they could easily be <!nopython !stage1>.
> 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.
I'm not sure I agree with this. A maintainer can't reliably know all the
cycles their package might be involved in over time, sure, but they *can*
know what is the bare minimum of functionality that their package can
have and still be useful for build-dependencies, and that's how I used
stage1 in src:dbus.
S
