Re: Extending the build profile namespace
Helmut Grohne writes ("Extending the build profile namespace"):
> * The nodoc profile is a bit strange. It is supposed to drop
> documentation from packages or to drop documentation packages. The
> former leads to packages whose content varies with profiles (which
> generally is bad)
I think there is nothing wrong with a build profile producing the same
packages with different content.
IMO someone (human or software) who specifies the use of a build
profile is responsible for knowing the semantic effect of the profile.
For this reason each profile name should come with a specification.
Earlier in your mail you skipped over the nocheck profile and asserted
that its semantics are to `mark droppable dependencies'. But the
semantics are also that when this profile is used, there is a greater
probability of generated nonfunctional packages (ie of failing to
detect bugs where without `nocheck', the brokenness would be detected
and the build would fail).
> and the latter mostly drops Arch:all packages, so
> in many cases simply doing an arch-only build achieves the same
> effect. If the only Architecture: all package from a source package
> is a -doc package, then generally the nodoc profile is not necessary
> (e.g. cargo and rustc). Just populate Build-Depends-Indep properly.
> Maybe we should revise rules for this profile?
I don't agree with this analysis at all. One thing you might want to
do is deliberately run builds of many packages in a situation where
you know you don't care about generating documentation (or would like
to save the space consumed by documentation).
For this to work, there has to be a way to specify such a build
without knowing the details of the package.
> Also some packages implement this as a non-profile
> DEB_BUILD_OPTIONS=nodoc (e.g. botch, brian, cython, dipy, isso, [...]
AIUI the difference between a build profile and a DEB_BUILD_OPTIONS
value is simply that a build profile is able to predictably[1] change
the set of build dependencies and/or the set of generated binary
packages.
[1] By predictably I mean that this is specified in a machine-readable
way, so that higher level build orchestration tools can make use of
the information.
ISTM that the nodoc build option should be phased out in favour of a
build profile. For compatibility, the specification for the nodoc
profile should say that nodoc builds should always be done with the
nodoc build option too. dpkg-buildpackage could handle this.
> * The various stage profiles serve vastly different needs. The common
> theme is breaking dependency cycles, but that's about where
> commonality ends.
...
> * It is generally not well defined what functionality is dropped in
> what stages. Instead, the stages are derived from practical need
> (which is good). Still, we loose track of whether these stages are
> still needed and whether they still work over time. I believe that
> this undefinedness is a bad property of these profiles and that we
> should therefore stop using them whenever feasible. Instead, I'd
> like to see specific profiles (e.g. drop Perl bindings). I
> acknowledge that this is the path to becoming more like Gentoo (USE
> flags), but maybe that's a good direction?
I don't think there is a real problem with unneeded stages, or broken
stages, lingering.
I could be wrong but I think the stage profiles are pretty easy to
keep in the affected packages and don't have a big maintenance cost.
If they are still needed, they will get tested, and be maintained.
If they aren't needed right now they may rot, but keeping them there
and half-working will make it easier if they are needed again. I
think it is better to keep them there than to flail about introducing
and removing them.
The stage* system avoids doing a lot of work to determine and describe
precisely the situation in an abstract way; rather, it is an explicit
and manually maintained bootstrap sequence (with a cross-archive
representation).
In general in Debian we keep lots of things which we're not sure are
still useful and which we're not sure are still working. Whenever we
remove such a thing it usually turns out someone was relying on it, or
that someone had been using it in a way that avoids the breakage.
> Given the above analysis, I see two immediate needs for change in the
> handling of build profiles:
>
> 1) We should provide a namespace (profile name prefix) where packages
> can add their own custom profiles at will and where there is room
> for experimentation. Such a namespace would improve the metadata for
> packages like gcc-$VER, cyrus-sasl2, dnsmasq and reprepro. I propose
> that packages can use "pkg.$sourcepackage.$anyting" whenever the
> maintainer of $sourcepackage agrees with that use.
Very good idea.
> 2) Given the mess with stage profiles, I think that we should provide
> some better way for generic feature profiles (like Gentoo USE flags)
> that are to be used consistently by multiple packages. Of course,
> Debian is not going to replicate the diversity of Gentoo's USE
> flags, but adding them driven by demand may be a sane choice. For
> instance, audit, libcap-ng, libprelude and newt could use a "nopython"
> profile for disabling Python language bindings instead of gaining a
> meaningless "stage1" profile for breaking dependency cycles. I see
> immediate practical use (for replacing stages) in profiles disabling
> Go (nogolang), Java (nojava), Perl (noperl) and Python (nopython)
> bindings and vague need for disabling Apparmor support (noapparmor),
> Bluetooth support (nobluetooth), Lua bindings (nolua), SELinux
> support (noselinux), systemd integration (nosystemd), and systemtap
> support (nosystemtap).
I'm not a cross expert but I think this is a bad idea, at least if
done for this reason. The benefit of the current stage profiles is
that it is easy for a cross bootstrap orchestration tool to know what
to do.
Your suggestion, if implemented, would:
1. Complicate the metadata for what is a pretty minority feature.
This imposes more work on package maintainers in general and more
work on those trying to get the boostrap to work.
2. Require the implementation of a new bootstrap planner which would
be able to mine the profile-specific build-dependency information
to construct a bootstrap plan.
3. Still not address the `problem' you identify that the stage*
dependencies implicitly violate dependency contracts. The only way
to address this problem fully would be to provide explicit
representation in the dependency system for interfaces like
`fontforge with embedded python support' (or conversely for
`fontforge without embedded python support'). I think this would
be very complicated.
4. Items 2 and 3 above iteract very badly. I think it may be
impossible to do 2 without also doing 3.
So in summary
> Furthermore, having a way to distinguish "safe" (package set changing)
> from "unsafe" (content changing) profiles would be very helpful.
I agree that this is a useful distinction (although I don't
necessarily agree with your terminology). Given that you propose to
allow package maintainers to make up random shit in their bit of the
profile namespace, how do you imagine such a package maintainer
publishing the information about the semantics of their build
profiles, so that tools may find it ?
Ian.
Reply to: