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
