Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

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

 



On 03. 04. 20 20:23, Stephen Gallagher wrote:
Fabio Valenti made this comment in the FESCo ticket[1].

"Side note: I think more people would be amenable to including
"conditionals" into their packages if they weren't only shown off as
`%if eln this else that`. I think there's more value in doing "feature
flags" rather than conditionalize everything based on the `dist` tag,
for example something like this might even be useful in fedora
branches (e.g. for bootstrapping):

```spec
# at the top of the .spec file, where it's easily visible
%if 0%{?eln}
%bcond_with docs
%else
%bconf_without docs
%endif

# ...

%if %{with docs}
# do something
%endif
```

This makes conditionals (when they are necessary) much easier to
maintain (and understand), in my experience."

First, let me say that I agree wholeheartedly and I think that when
we're using conditionals this is the best way to do it.

I agree that if we're using conditionals this is the best way to do it.
I still think that having two otherwise identical specfiles only differing that:

RHEL spec has:

    %bcond_with docs

And Fedora spec has:

    %bcond_without docs

...is a saner way to handle the differences. However I agree that this is not the only way to do it and if we ends up using %rhel/%fedora conditionals, they should preferably only be ever used to flip bconds.

I had some thoughts here on how we could accomplish the above without
cluttering the spec file (though it does add a bit of complexity to
the dist-git contents). We could take a page from build-systems and
have essentially a separate "configure" and "build" step for RPM. (No,
I'm not proposing changes to RPM itself).

At the top of the specfile (above even the `Name:` directive), we
would have constructs of the following type:

%if 0%{?rhel} < 9
%include rpmconfig_rhel_old.inc
%elif 0%{?rhel} >= 9
%include rpmconfig_rhel_new.inc
%else
%include rpmconfig_fedora.inc
%endif

Contents of rpmconfig_rhel_old.inc:
%bcond_without pregen_docs
%bcond_with openssl3

Contents of rpmconfig_rhel_new.inc:
%bcond_without pregen_docs
%bcond_without openssl3

Contents rpmconfig_fedora.inc:
%bcond_with pregen_docs
%bcond_without openssl3


Then the main specfile can use the `%if %{with FEATURE}` construct
instead of dealing with the clutter in the main specfile (and merges
will likely be easier).

OTOH I must say the other part here is not a very good idea, to quote an RPM developer:

Note that you do *not* want something based on %include. Using %include turns
spec from a standalone entity into something that requires external files in
certain paths, causing lots of unnecessary pain and grief and endless stream
of bugs that we cannot fix.
from https://pagure.io/packaging-committee/pull-request/942#comment-106873

Yes, but sooner than later those specs will find their way out of the repo.
People expect to toss, pass and parse spec files around without having to
also pass additional sources. That's one of the *pros* of spec format compared
to eg dpkg, and using %include breaks that. People will be unhappy.

from https://pagure.io/packaging-committee/pull-request/942#comment-106997

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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