Re: Extending the build profile namespace
2016-04-24 20:08 Helmut Grohne:
* The nocheck profile is the cousin of DEB_BUILD_OPTIONS=nocheck and
must be used in conjunction with that option. Its sole purpose is to
mark droppable dependencies and it seems to be used properly. I would
be happy to see even wider adoption (e.g. #787044), because this is
one of the easiest and safest ways to work on bootstrap problems.
I think that having this duplication (potentially with different
meanings or scopes, and maybe diverging further over time as used on the
field) is undesirable in the long run.
Perhaps these OPTIONS and PROFILES should be merged, in a way that if
one is enabled, the other also is. (Is this the plan already?)
(Same applies for "nodoc*").
Maybe this has already been considered and discarded, but from having
thought about this in the past, I think that option to solve this would
be:
- to have fine-grained and well-defined knobs in DEB_BUILD_OPTIONS
(e.g. nodoc, nocheck, noLANGbindings...), possibly further
standardised than today and that can be used independently of profiles
-- this is also your idea, as far as I can tell
- and then DEB_BUILD_PROFILE turning one or several of these knobs at
once, consistently across packages (e.g. a feasible cross-stage1
always implying both "nodoc" and "nocheck" and dropping all language
bindings, among others).
Even if for many packages it wouldn't be necessary to drop some/most
functionality, the target for bootstrap builds should be IMO to only
enable the minimal necessary deps for the packages to work (to save time
and space when [re]bootstrapping, if nothing else).
(More on this below)
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.
Gentoo-style USE flags are based on the idea that, rather than having an
enable-all approach and having "negative" options (disabling specific
stuff), they should be changed to behave as "positive" (have a baseline
of "disable everything non-essential" and enable functionality as
needed/demanded).
Since Debian is usually about full-functionality-enabled by default, and
this is what rdeps expect and so on, I think that this approach means
going against the tide.
Your proposal is more like a DONTUSE flags :) -- like "enable disabling
functionality".
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'd consider also a "noaudit", it's a lot of rdeps and the use of this
framework is not needed at the time of bootstrapping.
Furthermore, having a way to distinguish "safe" (package set changing)
from "unsafe" (content changing) profiles would be very helpful.
Obviously you have more experience here, and I don't want to say that
this idea is without merits.
However, in general as a part-time-porter, I don't think that
distinguishing between safe and unsafe is important for the general case
of bootstrapping and architecture (it's more important for the case of
checking whether everything is bootstrappable).
One assumes that the packages being built are just a means to an end,
that they will have to be rebuilt with full funcitonality in any case.
The failure (or unsafeness) of packages to behave normally doesn't
matter, as long as it eventually allows to reach a stage where your
whole set can be used to rebuild and improve itself to a full-fledge
Debian.
Unless I hear objections, I will start using those profiles and ask
lintian maintainers to relax profile checks.
This message is not an objection, just thinking aloud in the case that
the ideas above help in some way (even if only to gauge the mindset).
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
Reply to: