[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: