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.montez...@gmail.com>
