Hi, Miro,
On Fri, Mar 27, 2020 at 12:35 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
>
> On 26. 03. 20 16:13, Miro Hrončok wrote:
> > On 25. 03. 20 17:10, Miro Hrončok wrote:
> >>> Finally, of the set of packages that we're going to be including, we
> >>> anticipate around 200-300 of them will have distro conditionals that
> >>> need investigation (with fewer needing actual modification). The ELN
> >>> SIG will be doing this initial investigation and will provide guidance
> >>> (and/or PRs) to affected packagers.
> >>
> >> My concerns still remain, although I am now not so scared that this will
> >> alienate the community. Now the concern is more personal (= previously I was
> >> worried that everybody will be encouraged to use the conditionals, while now
> >> I'm mostly concerned they I will be encouraged to use the conditionals).
> >
> > Also, to make this more clear:
> >
> > I am not worried about the conditionals because I would need to maintain them.
> >
> > I am worried that "my" packages will be harder to co-maintain (or generally
> > changed) by people from the community.
> >
> > As an example, I will know the RHEL 9 (10, 11...) plans and I can structure my
> > specs accordingly. However if there is a passionate Fedora contributor who would
> > like so submit a Pull Request for e.g. python-virtualenv to update it to a new
> > fancy version that does things differently, they are not familiar about our RHEL
> > plans and they would not be capable to wrap their head around such conditionals.
> > They would also need to rebase any RHEL-only patches for this to work. At the
> > end, they are more likely to just go away and not do it at all.
>
> Another example. In a corporate meeting with the product owners/managers, we
> decide that the next major RHEL release will include Brainfuck 7 because it an
> LTS release. Fedora rawhide is updated to Brainfuck 7 and everything is nice and
> fine.
>
> Later, Brainfuck 8 is released. The Fedora community wants this new version,
> because it finally has a support for Brainloller and the Ook! stack depends on
> this new feature. The Ook! stack is not planned to be in RHEL, so from RHEL
> perspective, this new feature is not that important. But the Ook! SIG obviously
> wants this.
>
> The RHEL maintainer now needs to artificially block the Brainfuck 8 update from
> rawhide until next RHEL is branched (they probably cannot even share when this
> is going to be with the Fedora community because NDA). This prevents the "First"
> foundation of Fedora (and TBH it also prevents "Friends", the RHEL maintainer is
> actively blocking the Ook SIG here by their (in)action).
>
>
> The conditional approach will only allow this:
>
> %if 0%{?rhel}
> Version: 7.4.5
> %else
> Version: 8.0.0~rc1
> %endif
>
> (And I assume the rest of the spec file would need major %if/%else mess as well,
> because Brainfuck 8 is built with meson, while Brainfuck 7 is built with
> autotools. Or the implementation language changed from C to Rust...)
Thank you for bringing this example.
I agree with your point that in case of choices like this,
conditionals do not make sense. It is a branch. But this branch in my
opinion has nothing to do with ELN.
ELN is not RHEL. It is a development tool, which gives us a preview,
so that we can plan the work better. We are not planning to release
RHEL from ELN packages.
Therefore ELN is all about the form, not the content. The goal of this
project is to apply downstream form to Fedora Rawhide content and see
what issues RHEL or downstream in general will have in the future. But
the work itself doesn't always have to happen in Fedora Rawhide. ELN
doesn't bring any new changes here, as you keep working with upstream
and downstream the way you as package maintainer worked before.
So while we may ask for some adjustments to Fedora spec files to fit
into that EL-form, these adjustments are structural. And in the case
you have described I am against branching not because I would like to
have conditional instead, but because I don't want to fork Fedora
Rawhide content into something else in ELN at all.
I think the kind of branching you have described should happen
somewhere down the line, in RHEL(CentOS Stream maybe).
> And trust me, you don't want to maintain that. It is not maintainable. And it
> has problems like this:
> https://pagure.io/copr/copr/issue/1315
If I understand it correctly, this only illustrates the issue which
may happen, not the example itself. As the reasons to have conditional
in that particular spec file are not relevant to ELN.
> Another approach is compat packages, but Brainfuck 8 is backwards compatible
> with 7, so it brings no benefit for Fedora.
>
> Another approach is modularity, but the Ook! SIG doesn't want to use modules
> because they want their Ook-based apps to be easily available to Fedora users.
>
> Sorry for going artificial with the example, but I didn't want you to say "you
> are always talking about Python, what you say is Python specific" -- because it
> isn't.
>
> --
> 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
--
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
