On Fri, Apr 3, 2020 at 8:23 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
>
> On Fri, Apr 3, 2020 at 1:27 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote:
> >
> > On Thu, Apr 02, 2020 at 10:32:31PM +0200, Nicolas Mailhot via devel wrote:
> > > Would it be possible to formalize the kind of spec processing ELN wants
> > > available in a set of generic operations with generic arguments (or
> > > control variables)?
> > >
> > > I would not mind seeing a set of ELN macro calls in my rawhide specs,
> > > that evaluate to nothing for Fedora. *declarative* syntax is a lot less
> > > scary maintenance-wise than free-form spec programming.
> >
> > This seems like a great suggestion in general and the direction we should be
> > going anyway.
>
> 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 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).
I was also thinking about something alone those lines.
But if I understood Neil's comment right in [1] then we don't even
need the .inc-files in each spec file, because the flag can be
switched globally on the build environment.
We would need a dedicated namespace for such flags and the way to
track them. And then we could build Fedora Rawhide according to the
predefined set of global switches.
[1] https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/UOO3JNM7S4HKBR5VFNVAQT6J33TZQLWV/
> _______________________________________________
> 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
--
--
Aleksandra Fedorova
bookwar
_______________________________________________
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
