Re: %bcond_with/%bcond_without

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

 



On Mon, Apr 06, 2020 at 09:03:08AM +0200, Petr Pisar wrote:
> On Sat, Apr 04, 2020 at 03:14:07PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > This is not what we were discussing. This should be compared with
> > %bcond_with/%bcond_without, which would looks like this:
> > 
> > %if 0%{?fedora} > 0
> > %bcond_without docs
> > %bcond_without tests
> > %endif
> > 
> > %if 0%{?rhel} > 0
> > %bcond_with docs
> > %bcond_without tests
> > %endif
> > 
> > Which IMO clearly loses the contest.
> > 
> > Returning to the one-definition vs. multiple-definitions issue:
> > I think I'd prefer the shorter version, though I admit it's pretty
> > close in this case.
> > 
> > The biggest usage problem is that rpm does not verify that everything
> > is assigned, so (with a longer list) it's fairly easy to forget to
> > define one of the items in one of the cases, silently leaving a
> > feature disabled.
> > 
> > Also, things quickly get complicated when issues depend on one another:
> > %define_cond docs 0%{?fedora} > 0 || 0%{rhel} >= 8
> > %define_cond tests 1
> > %define_cond doc-tests %{with_docs} && %{with_tests} && 0%{?rhel} >= 9
> > 
> > Ideally, we would be able to do both, and e.g. in this case use
> > the "verbose" style for the first two switches, and the one-line style
> > for the third condition.
> > 
> Ideally, there should be no dist-bound conditions (%if 0%{?rhel} > 0). In the
> spec file should only be a list of the switches with their default state
> (on/off), possibly with a documentation:
> 
> # Build an HTML manual with ascidoc
> %bcond_without docs
> # Perform the tests
> %bcond_without tests
> 
> The dist-bound conditional should be specified outside the spec file,
> preferably on a distribution-level. E.g. RHEL decides that it does not
> want to distribute a documentation, then it defines "%_without_docs 1" in srpm
> build root macros.

Standarization of common defines is a different aspect of the whole
issue. To make them work, we would need to standarize such defines and
include them in Packaging Guidelines. (I'm only aware of 'bootstrap'
being mentioned in PG right now.) I think it would be generally useful
to have 'bootstrap', 'docs', and 'tests' standarized.

> This way the package becomes fully agnostic of the distribution it builds in.
> No hard-coded exceptions anymore.

I don't think this would ever be possible — there's plenty of other
conditions which don't fall into such neat global categories.

Zbyszek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux