Re: debian/rules and DEB_BUILD_PROFILES vs _OPTIONS
Christian Kastner:
> On 2020-09-06 23:27, Mattia Rizzolo wrote:
>> On Sun, Sep 06, 2020 at 10:53:05PM +0200, Christian Kastner wrote:
>> The thing is, according to the build profile spec, if you specify nodoc
>> or nocheck in _PROFILES you *MUST* also specify it on _OPTIONS (talking
>> about when you do the build), so…
>
> That's why I find this part odd:
>
>>> Looking at random packages, newer packages seem to favor just checking
>>> DEB_BUILD_PROFILES
>
> Given what was said above for the major use cases nodoc and nocheck,
> _OPTIONS > _PROFILES, so I wonder why _PROFILES is favored.
>
>>From Niels' response, I guess one can conclude why this isn't an issue
> for the nodoc case.
>
>> You should read the manpages for more details.
>
> I did, and while _OPTIONS and_PROFILES are both explained, the
> relationship between them (if any) is not.
>
Fundamentally, the difference between the two are:
* _PROFILES is a "new"[0] thing with a specific purpose to reduce
build-dependencies (at least in this case). It ends up in d/rules
for skipping builds of specific packages (e.g. "nopython")
* _OPTIONS is the thing that has been here since the "dawn of time" to
enable the builder to tweak the build in a standardized way.
(Note that their definitions do not overlap)
Basically, we ended up in the situation like this with nocheck[1]:
* We had _OPTIONS with nocheck for at least a decade and probably more.
- I.e. _OPTIONS is what everyone wrote in their d/rules file to
implement policy.
* We invented _PROFILES and supported nocheck to assist cross-builders
and bootstrappers, who generally want as few build-depends as
possible even at the expense of running tests (cross-builders often
cannot run them anyway).
- I.e. _PROFILES is what the dependency resolvers look for when
deciding which build-depends to install.
And that is how you end up with WET Debian packaging.
I hope that cleared the relationship between _OPTIONS and _PROFILES and
how we got here.
At this level, it might look deceptively easy to "fix" this problem
("Couldn't we just do X and then it will solve everything?"). However,
I have deliberately avoided to dive into "X" - among other because I am
not sure I can accurately represent the /current/ views of everyone. If
you are interested in that, I would recommend some off-list research first.
~Niels
Reply to: