On Tue, Jul 18, 2017 at 10:33:06AM +0100, Simon McVittie wrote: > 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.
That may all be true, but simply using "stage1" is harmful in the long run, because it renders "stage1" meaningless. We have a pile of "stage1" profiles in the archive already and we essentially lost structure on them. Some modify binary packages. Others drop binary packages. You cannot tell what "stage1" does without looking at a particular source package. The only meaning left is that it is often used with bootstrapping in unspecified ways, but it doesn't even tell whether that's native or cross and whether it actually is legacy. > 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. It seems that the essence of dbus' stage1 is to reduce as much functionality as possible. Why not call it pkg.dbus.minimal instead? That name would directly carry the intention. (See Josch's mail for rationale.) We should actually go one step further: We should require that any profile being used is documented in a "canonical" place. For "standard" profiles (nocheck, nopython, ...) that'll be some central document (e.g. policy). For extension profiles (pkg.$sourcepackage.$anything) that'll be debian/README.source or something similar. Without such documentation we'll only enlarge the mess we have with "stage1" now. Let me give a recent example for comparison. I recently had to add a profile to unbound to break a cycle. unbound builds itself four times with varying ./configure flags. Reducing it to the one relevant build pass building the shared library was the obvious thing to do. I could have called the profile "stage1", but I think "pkg.unbound.libonly" much better tells what it does. The very same logic applies to dbus, no? While at it, I'd like to emphasize that it is not forbidden or even discouraged to use pkg.foo.someprofile in source package bar. The only requirement is that foo's maintainer agrees with that use (e.g. by documenting how it is supposed to be used). I see no urgency in removing "stage1" profiles now. They're a mess, but a working mess. What I'd like to avoid is furthering the mess. So let's not add more "stage1" than we have now please. Use descriptive profiles for new stuff. Helmut
