----- Original Message -----

From: "Vít Ondruch" vondruch@redhat.com To: devel@lists.fedoraproject.org Sent: Wednesday, April 1, 2020 10:19:08 AM Subject: Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

So although this update clarifies some part, we have not moved anywhere:

=== Can we do this in a branch instead of in master? ===

This adds no value to the current approach where Red Hat maintainers
would manually merge their changes into the internal build
infrastructure. There's no way to automate the sync from the `master`
branch to the `eln` branch that wouldn't break and require maintainer
involvement. Attempting to branch only individual packages would
introduce significant complexity in the build process as well, leading
to far more opportunity for bugs. Lastly, even the most diligent of
maintainers can forget to sync every change to a new branch, thus
leaving us in a situation where the `eln` branch has fallen behind and
is no longer providing an accurate view of whether the package is still
building or functioning in that environment.

I'm actually doing this in my COPR all rubygems[1], as a part of my (mostly automated) workflow. It does add some manual overhead, but I think it's doable (maintaining the additional branch), but only if one can force-push into it.

Regards, Pavel

[1] https://copr.fedorainfracloud.org/coprs/pvalena/rubygems/

I wonder where this comes from. I am participating in this thread,
representing Ruby maintainers in RHEL and Fedora, in other places of the
thread, I see Miro Hrončok, Tomáš Orsava and Pert Viktorin representing
Python RHEL and Fedora maitainers, as well as Petr Písař, the RHEL and
Fedora representative of Perl. All in all, it represents ~1/2 packages
in Fedora/RHEL. I hope that I can say that these people shares a view
that branch, fork, PR is the way to go.

Yet we are not able to convince you. So I wonder who this proposal
actually represents? Who is the target audience? Who are the Red Hat
maintainers you mentioned in the proposal?


Vít



Dne 31. 03. 20 v 17:31 Stephen Gallagher napsal(a):
> I sent out the V2 version of the Change on Friday and then promptly
> managed to injure myself and be away from email until today. I've read
> through the email threads again this morning and I decided that,
> rather than try to address them one by one, I'd try again with a V3
> that hopefully answers some of the repeated questions and concerns on
> that list.
>
> Please see the newly-updated
> https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> for more details[1].
>
>
> [1]
> https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose&type=revision&diff=569904&oldid=569809

Dne 01. 04. 20 v 16:01 David Cantrell napsal(a):

On Wed, Apr 01, 2020 at 10:19:08AM +0200, Vít Ondruch wrote:

...

So although this update clarifies some part, we have not moved anywhere:

=== Can we do this in a branch instead of in master? ===

This adds no value to the current approach where Red Hat maintainers
would manually merge their changes into the internal build
infrastructure. There's no way to automate the sync from the `master`
branch to the `eln` branch that wouldn't break and require maintainer
involvement. Attempting to branch only individual packages would
introduce significant complexity in the build process as well, leading
to far more opportunity for bugs. Lastly, even the most diligent of
maintainers can forget to sync every change to a new branch, thus
leaving us in a situation where the `eln` branch has fallen behind and
is no longer providing an accurate view of whether the package is still
building or functioning in that environment.

I wonder where this comes from. I am participating in this thread, representing Ruby maintainers in RHEL and Fedora, in other places of the thread, I see Miro Hrončok, Tomáš Orsava and Pert Viktorin representing Python RHEL and Fedora maitainers, as well as Petr Písař, the RHEL and Fedora representative of Perl. All in all, it represents ~1/2 packages in Fedora/RHEL. I hope that I can say that these people shares a view that branch, fork, PR is the way to go.

Yet we are not able to convince you. So I wonder who this proposal actually represents? Who is the target audience? Who are the Red Hat maintainers you mentioned in the proposal?

I think the FAQ entry above could be phrased better, but my understanding is that we should really want rawhide to be where upstream RHEL work happens. Creating another branch for this work effectively creates two rawhides and I think ELN would suffer as a result.

Of course what can go into Rawhide should go into Rawhide, but that are not ELN/RHEL conditionals.

Vít

Another thing to consider is that we should want ELN builds happening as rapidly as rawhide builds.  ELN is not something to set up and maintain as it were RHEL.

Thanks,

...

Dne 31. 03. 20 v 17:31 Stephen Gallagher napsal(a):

...

I sent out the V2 version of the Change on Friday and then promptly managed to injure myself and be away from email until today. I've read through the email threads again this morning and I decided that, rather than try to address them one by one, I'd try again with a V3 that hopefully answers some of the repeated questions and concerns on that list.

Please see the newly-updated https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose for more details[1].

[1] https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Comp... _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org

---

devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org

On Thu, Apr 02, 2020 at 03:56:05PM -0400, David Cantrell wrote:

On Wed, Apr 01, 2020 at 05:32:08PM +0200, Vít Ondruch wrote:

...

Of course what can go into Rawhide should go into Rawhide, but that are not ELN/RHEL conditionals.

I think this is part of what ELN is trying to address to make all of our lives easier. For the longest time we've had a separation between Fedora and RHEL dist-git and that means we double (or more) our work. Conditionals in rawhide spec files to alter the build is exactly the kind of stuff we should have in a rawhide spec file. If we don't do it there then we're doing it elsewhere and the work will lag. Personally, I'd prefer to maintain this stuff in one place.

In other words your want to develop RHEL in Fedora. Adding RHEL conditionals into Fedora is exactly that. I fully understand that it significantly helps RHEL maintainers. But this goal should be clearly stated in the Change page. So far Aleksandra denied it. It's necessary to realize that Fedora has rules against it:

only macros and conditionals for Fedora and EPEL are allowed to be used in Fedora Packages. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_legibility

Another way I'm thinking about it is the downstream consumption of rawhide. sgallagh, maybe you could add a graphic depicting this in the proposal. I view rawhide as what is common for all descendents: Fedora, CentOS, and RHEL.

I'm not against making Rawhide sources a meta distribution. That means when building a Rawhide spec file in Fedora, yout get a package that fits into Fedora and when building it on RHEL, you get a package that fits into RHEL. I already do that by adding distribution-agnosting, feature-oriented build conditionals into the spec files and then I enable/disable the features at one place (a srpm macros package or a module macros section). But without a proper support from RPM and globally enforced namespace rules it's one big hack that does not scale well and that prone to rot because nobody rebuilds Rawhide sources in RHEL with every change.

-- Petr

On Wed, Apr 1, 2020 at 6:31 AM Miro Hrončok mhroncok@redhat.com wrote:

On 01. 04. 20 10:53, Zbigniew Jędrzejewski-Szmek wrote:

...

On Tue, Mar 31, 2020 at 11:31:38AM -0400, Stephen Gallagher wrote:

...

I sent out the V2 version of the Change on Friday and then promptly managed to injure myself and be away from email until today. I've read through the email threads again this morning and I decided that, rather than try to address them one by one, I'd try again with a V3 that hopefully answers some of the repeated questions and concerns on that list.

...

To enable ELN (once the repository is composed):

$ dnf install fedora-repos-eln $ dnf distro-sync

I don't see this part explained. Those additional packages will haves NEVRAs always lower than rawhide packages (".eln" < ".fc33".). So this distro-sync will be a noop?

A wild guess: If that repo has lower "cost", will distro-sync prefer packages with lower EVR because they come form that repo?

I think if the repo has a higher priority or lower cost, it might work? I'm not sure...

On Wed, Apr 1, 2020 at 6:46 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:

On Wed, Apr 01, 2020 at 12:30:13PM +0200, Miro Hrončok wrote:

...

On 01. 04. 20 10:53, Zbigniew Jędrzejewski-Szmek wrote:

...

On Tue, Mar 31, 2020 at 11:31:38AM -0400, Stephen Gallagher wrote:

...

I sent out the V2 version of the Change on Friday and then promptly managed to injure myself and be away from email until today. I've read through the email threads again this morning and I decided that, rather than try to address them one by one, I'd try again with a V3 that hopefully answers some of the repeated questions and concerns on that list.

...

To enable ELN (once the repository is composed):

$ dnf install fedora-repos-eln $ dnf distro-sync

I don't see this part explained. Those additional packages will haves NEVRAs always lower than rawhide packages (".eln" < ".fc33".). So this distro-sync will be a noop?

A wild guess: If that repo has lower "cost", will distro-sync prefer packages with lower EVR because they come form that repo?

I don't think so: "cost — ... It is useful to make the library prefer on-disk repositories to remote ones."

But there's a "priority" option: "If there is more than one candidate package for a particular operation, the one from a repo with the lowest priority value is picked, possibly despite being less convenient otherwise (e.g. by being a lower version)."

This should do the trick. The mechanism should be described in the Change page too.

(Note: I had a sense of deja-vu, because 'priority' was already discussed in the context of this Change, but it was koji priority for scheduling tasks, not package installation.)

Right, the intent here is to have the fedora-repos-eln subpackage provide a repo at priority level 98 (default being 99, lower numbers "win"). I left it out because generally Change Proposals aren't required to document every minor implementation detail.

On Wed, Apr 1, 2020 at 3:24 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:

On Wed, Apr 01, 2020 at 11:40:49AM -0400, Stephen Gallagher wrote:

...

On Wed, Apr 1, 2020 at 6:46 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:

...

On Wed, Apr 01, 2020 at 12:30:13PM +0200, Miro Hrončok wrote:

...

On 01. 04. 20 10:53, Zbigniew Jędrzejewski-Szmek wrote:

...

On Tue, Mar 31, 2020 at 11:31:38AM -0400, Stephen Gallagher wrote:

...

I sent out the V2 version of the Change on Friday and then promptly managed to injure myself and be away from email until today. I've read through the email threads again this morning and I decided that, rather than try to address them one by one, I'd try again with a V3 that hopefully answers some of the repeated questions and concerns on that list.

...

To enable ELN (once the repository is composed):

$ dnf install fedora-repos-eln $ dnf distro-sync

I don't see this part explained. Those additional packages will haves NEVRAs always lower than rawhide packages (".eln" < ".fc33".). So this distro-sync will be a noop?

A wild guess: If that repo has lower "cost", will distro-sync prefer packages with lower EVR because they come form that repo?

I don't think so: "cost — ... It is useful to make the library prefer on-disk repositories to remote ones."

But there's a "priority" option: "If there is more than one candidate package for a particular operation, the one from a repo with the lowest priority value is picked, possibly despite being less convenient otherwise (e.g. by being a lower version)."

This should do the trick. The mechanism should be described in the Change page too.

(Note: I had a sense of deja-vu, because 'priority' was already discussed in the context of this Change, but it was koji priority for scheduling tasks, not package installation.)

Right, the intent here is to have the fedora-repos-eln subpackage provide a repo at priority level 98 (default being 99, lower numbers "win"). I left it out because generally Change Proposals aren't required to document every minor implementation detail.

It's not a minor implementation detail. The subject of priority came up before in the thread where people were wondering about version ordering. What priority level will be used is indeed something that doesn't need to appear in the change page, but the general approach should IMO appear there.

By providing an overview of implementation choices you make it possible for people to think about various corner cases and possibly find issues that that otherwise could only discover once the implementation is done and it's much harder to change stuff.

Well, Change Proposals aren't design documents. I would prefer to change the document to read more like "This will need to be implemented in such a way that contents of the ELN repository would be preferred by the software management tools over the standard Fedora packages, even when the latter are of a higher version." I prefer not to put implementation details in places like this; I'd rather describe the expected behavior and trust that those implementing it will find an appropriate mechanism.

Do you want me to list some of the other approaches we considered and discarded before we settled on `priority`? I don't think that belongs in a Change Proposal either, but since apparently we can't get Changes approved anymore without having the complete implementation beforehand, I guess we can add that too.

* Instead of using `priority`, we *could* opt to provide all of the ELN content as a large Module. That has overhead problems that make it not worthwhile. * We could force all ELN builds to have epoch+100 when they rebuild (this has problems with future updates). * We could modify the RPM/libdnf stack to automatically install different versions of the RPMs based on available hardware. (We don't have the available resources for another Modularity-level effort.)

On Wed, Apr 01, 2020 at 03:55:19PM -0400, Stephen Gallagher wrote:

On Wed, Apr 1, 2020 at 3:24 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:

...

On Wed, Apr 01, 2020 at 11:40:49AM -0400, Stephen Gallagher wrote:

...

On Wed, Apr 1, 2020 at 6:46 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:

...

On Wed, Apr 01, 2020 at 12:30:13PM +0200, Miro Hrončok wrote:

...

On 01. 04. 20 10:53, Zbigniew Jędrzejewski-Szmek wrote:

...

On Tue, Mar 31, 2020 at 11:31:38AM -0400, Stephen Gallagher wrote: >I sent out the V2 version of the Change on Friday and then promptly >managed to injure myself and be away from email until today. I've read >through the email threads again this morning and I decided that, >rather than try to address them one by one, I'd try again with a V3 >that hopefully answers some of the repeated questions and concerns on >that list.

>To enable ELN (once the repository is composed): > >$ dnf install fedora-repos-eln >$ dnf distro-sync

I don't see this part explained. Those additional packages will haves NEVRAs always lower than rawhide packages (".eln" < ".fc33".). So this distro-sync will be a noop?

A wild guess: If that repo has lower "cost", will distro-sync prefer packages with lower EVR because they come form that repo?

I don't think so: "cost — ... It is useful to make the library prefer on-disk repositories to remote ones."

But there's a "priority" option: "If there is more than one candidate package for a particular operation, the one from a repo with the lowest priority value is picked, possibly despite being less convenient otherwise (e.g. by being a lower version)."

This should do the trick. The mechanism should be described in the Change page too.

(Note: I had a sense of deja-vu, because 'priority' was already discussed in the context of this Change, but it was koji priority for scheduling tasks, not package installation.)

Right, the intent here is to have the fedora-repos-eln subpackage provide a repo at priority level 98 (default being 99, lower numbers "win"). I left it out because generally Change Proposals aren't required to document every minor implementation detail.

It's not a minor implementation detail. The subject of priority came up before in the thread where people were wondering about version ordering. What priority level will be used is indeed something that doesn't need to appear in the change page, but the general approach should IMO appear there.

By providing an overview of implementation choices you make it possible for people to think about various corner cases and possibly find issues that that otherwise could only discover once the implementation is done and it's much harder to change stuff.

Well, Change Proposals aren't design documents. I would prefer to change the document to read more like "This will need to be implemented in such a way that contents of the ELN repository would be preferred by the software management tools over the standard Fedora packages, even when the latter are of a higher version." I prefer not to put implementation details in places like this; I'd rather describe the expected behavior and trust that those implementing it will find an appropriate mechanism.

I disagree, both to "aren't design documents" and to the usefulness of providing detail.

Change pages often describe what will happen in detail. Just look at any of the pages from F32 list, e.g. [1-5]. The ones that don't describe implementation details are usually straightforward changes like gcc/binutils/dnf/language stack version bumps where the packaging changes are trivial.

In fact, for [4] below I had to provide the complete list of affected packages in the fesco ticket, and I think it was totally appropriate.

[1] https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer [2] https://fedoraproject.org/wiki/Changes/FontLangProvidesToLangpacks [3] https://fedoraproject.org/wiki/Changes/Stop-Shipping-Individual-Component-Li... [4] https://fedoraproject.org/wiki/Changes/Systemd_presets_for_user_units [5] https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format

Do you want me to list some of the other approaches we considered and discarded before we settled on `priority`? I don't think that belongs in a Change Proposal either, but since apparently we can't get Changes approved anymore without having the complete implementation beforehand, I guess we can add that too.

Yes, I think it'd be totally OK to describe alternative approaches and their relative merits. For something as complicated as this Change, airing design choices in public discussion should be a completely obvious step.

I *want* this change to succeed, but a lot of the discussion is people simply clamoring for information, often without any immediate result. I completely don't understand the reluctance.

Zbyszek

• Instead of using `priority`, we *could* opt to provide all of the

ELN content as a large Module. That has overhead problems that make it not worthwhile.

• We could force all ELN builds to have epoch+100 when they rebuild

(this has problems with future updates).

• We could modify the RPM/libdnf stack to automatically install

different versions of the RPMs based on available hardware. (We don't have the available resources for another Modularity-level effort.)

Dne 02. 04. 20 v 17:39 Stephen Gallagher napsal(a):

On Wed, Apr 1, 2020 at 4:34 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:

...

On Wed, Apr 01, 2020 at 03:55:19PM -0400, Stephen Gallagher wrote:

...

On Wed, Apr 1, 2020 at 3:24 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:

I disagree, both to "aren't design documents" and to the usefulness of providing detail.

Change pages often describe what will happen in detail. Just look at any of the pages from F32 list, e.g. [1-5]. The ones that don't describe implementation details are usually straightforward changes like gcc/binutils/dnf/language stack version bumps where the packaging changes are trivial.

I suppose I was overstating my reluctance here. I was trying to avoid setting a precedent for others in the future as to how much detail is required in the Change Proposals. I have made the following changes now:

https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Comp...

1. The repo priority is clearly stated in the "Detailed Description" section.
2. We've decided that there will be an option to maintain a package in

ELN separately from the master branch, but we are still working out the details of it (it won't be as simple as an 'eln' branch for complicated reasons that will become apparent in the near future). More information will be forthcoming about this.

Thank you for this.

Vít

Le jeudi 02 avril 2020 à 16:04 -0400, David Cantrell a écrit :

...

• We could force all ELN builds to have epoch+100 when they rebuild

(this has problems with future updates).

No need to modify the Epoch. And not advisable.

Wild idea (perhaps completely unworkable): upstream packagers hate free-form if el constructs, because experience show they bitrot.

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.

Regards,

On Fri, Apr 3, 2020 at 1:27 PM Matthew Miller mattdm@fedoraproject.org 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).

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):

# 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

On 03. 04. 20 22:36, Zbigniew Jędrzejewski-Szmek wrote:

So... could we please get a way to express this in rpm with a sane syntax:

%define_cond docs 0%{?fedora} > 0

(Naming and details of syntax are just examples, but the important parts are: one line, name before value, positive logic).

Yes please. See https://github.com/rpm-software-management/rpm/issues/941#issuecomment-58469...

On Fri, 2020-04-03 at 20:36 +0000, Zbigniew Jędrzejewski-Szmek wrote:

1. The logic is reversed: when I see "with" I think something is

enabled, when I see "without" I think something is disabled. But it's actually the other way around here, which I find very confusing and often get the condition reversed on the first try.

%bcond_with , means that you can add --with , so the default is without :)

in /lib/rpm/macros line 95 , you got the documentation.

On Sat, Apr 4, 2020 at 4:32 AM Aleksandra Fedorova alpha@bookwar.info wrote:

Something like:

%if 0%{?fedora} > 0 %define_cond docs 1 %define_cond tests 1 %endif

%if 0%{?rhel} > 0 %define_cond docs 0 %define_cond tests 1 %endif

Isn't the >0 superfluous? Just the "%if 0%{?fedora}" will evaluate as TRUE.

Thanks, Richard

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.

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

-- Petr

On Mon, Apr 06, 2020 at 11:53:55AM +0200, Nicolas Mailhot via devel wrote:

Le lundi 06 avril 2020 à 09:03 +0200, Petr Pisar a écrit :

...

# Build an HTML manual with ascidoc %bcond_without docs # Perform the tests %bcond_without tests

I feel the above syntax is hopeless. You need boilerplate (in all eln specs!) to explain that foo_without tests means enabling tests.

Good syntax does not need line-by-line comments.

The comments are not because of a bad syntax of %bcond_without. The comments explain what "docs" means. It can be a user manual for a package, it can be an API documentation for another package. While "docs" or "tests" looks self-decribing, there can be another identifiers whose meaning or implications are not so obvious. Here in the exampl it actually provides a very useful hint that if you enable documentation, you will need ascidoc (probably a new dependency).

If your only issue is the %bcond_with" and %bcond_without semantics, then I agree. But that's only a matter of chosing a better word. Nothing that cannot be fixed.

However, in my opinion, the build knobs should not be burried in the spec file for the sole purpose of building this one package.

The knobs should be visibile on RPM level in the source RPM package so that one can query a repository for what new depencies I will need when I enable "docs". Now one needs to inspect each spec file or rebuild the SRPMs. Quite an expensive task.

Also the knobs should be inheritable. There should be a distribution-level "docs" knob and then a package-level "docs" knob. So that a distribution can disable/enable the documentation everywhere with one switch and at the same time can specify the exceptions for the individual packages.

I really recommend to people interested in this topic to look on Gentoo USE flags because this is a feature extensively used there so it's more probable it's done right there:

A packager's view https://devmanual.gentoo.org/general-concepts/use-flags/index.html A user's view <https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/ A USE flag index https://www.gentoo.org/support/use-flags/ A fancier USE flag index https://packages.gentoo.org/useflags/

-- Petr

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

On 03. 04. 20 22:36, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Apr 03, 2020 at 02:23:12PM -0400, 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):

# 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."

This is a side topic, and I didn't want to clutter the FESCo ticket with that. But here we have threads, so I hope that you'll forgive me ;)

If find the %bcond_with/%bcond_without pattern abhorrent.

1. The logic is reversed: when I see "with" I think something is enabled, when I see "without" I think something is disabled. But it's actually the other way around here, which I find very confusing and often get the condition reversed on the first try.

2. The value ('0%{?eln}') in this example is expressed before the name ('docs'), which is like saying 'value =: name'.

3. It takes five (!) lines to express the something that should be one line.

So... could we please get a way to express this in rpm with a sane syntax:

%define_cond docs 0%{?fedora} > 0

(Naming and details of syntax are just examples, but the important parts are: one line, name before value, positive logic).

A followup:

https://github.com/rpm-software-management/rpm/pull/1520

Hi, Miro,

On Thu, Apr 2, 2020 at 6:56 PM Miro Hrončok mhroncok@redhat.com wrote:

On 31. 03. 20 17:31, Stephen Gallagher wrote:

...

I sent out the V2 version of the Change on Friday and then promptly managed to injure myself and be away from email until today. I've read through the email threads again this morning and I decided that, rather than try to address them one by one, I'd try again with a V3 that hopefully answers some of the repeated questions and concerns on that list.

Please see the newly-updated https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose for more details[1].

[1] https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Comp...

A vote has been initiated at FESCo issue tracker:

https://pagure.io/fesco/issue/2365

I am reposing my reply here:

The change proposal received overly negative feedback by the packager community as represented both by RHEL¹ and non-RHEL maintainers. Despite being reworked several times, none of this feedback was reflected in the proposal, only new reasons why this is going to be done the original way were added. It seems that feedback is collected not to find the best technical solution, but rather to find ways to justify a solution that's already decided.

Key questions in the *Detailed Description* remain "out of scope of ELN" or not answered clearly. The proposal should address the impact on all major packaging styles, and while one side of the spectrum (packagers preferring single-spec with conditionals) is covered, there are very few concrete details on the other (packagers interested in simple spec files or completely uninterested in RHEL). The affected packagers are concerned that the current proposal does not in fact benefit Fedora (to an extent that would justify the disruptions), but rather addresses mainly a downstream RHEL concern using Fedora's resources.

While benefiting the entire Fedora/RHEL/CentOS/EPEL ecosystem is certainly a good goal, I believe that doing this in a way that alienates a significant part of our packagers is a disservice to Fedora. The concerned packagers believe that Fedora is (and should remain) the upstream for RHEL, not RHEL itself. This might be shifting us to the undesirable mindset that Fedora is only a test bed for RHEL or a RHEL alpha version.

I literally addressed this part three times already here on the mailing list. And three times I got ignored, with someone posting the same concern again. If you'd like to have a conversation, please listen to the replies you get.

I'll reiterate again:

ELN is a tool to develop Fedora. Conditionals for ELN packages are going to be applied in those places where it makes sense and where it is approved by the Fedora packager. Yes, we believe that adding the flexibility in Fedora deptrees and feature choices is beneficial to Fedora. It is Fedora flexibility, which can then be used by downstream, whatever the downstream would be. We are not going to enforce this vision, but we'd like to work with people who share it, to test if this can actually work.

We discard branching as the part of the ELN proposal, exactly because of the concern that Fedora infrastructure is going to be used by downstream maintainers to develop downstream packages. We DO NOT want that. That's why we say: if Fedora packager and downstream can not come up with the common solution on how to incorporate downstream changes in Fedora Rawhide, then downstream work can not and should not happen in Fedora (and as ELN is Fedora, it should not happen in ELN either).

Branching and dist git sync to downstream can and will happen, but on downstream terms and on downstream infrastructure. This work doesn't belong to Fedora, and therefore doesn't need to be discussed here in this change proposal.

Now you blame us for thing which we haven't proposed. And it is hard to have a proper conversation about technical details, when the goal of the effort is repeatedly misunderstood and misinterpreted.

For me this feels like a step back to the [discontinued Fedora Core](https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00091.html), where the packages that were included in RHEL could only be maintained by their RHEL maintainers. Fedora relies on the contributions of non-RHEL developers — and those often have little interest in downstream work. If we alienate the community contributors, it will ultimately lead to a worse RHEL down the road.

For the stated reasons I am *-1 for this change in its current form*.

As said on the mailing list, I'd appreciate if you take the feedback provided by the packagers more seriously and adjust the proposal accordingly.

As a side note, I'd like to continue the discussion on the mailing list, as I believe there's still plenty to discuss. That's why I'll also post this text there, so you can quote-reply.

---

¹ For any interested Red Hatters reading this: Apart form the feedback received on the devel mailing list, I discussed this internally with my Red Hat team, Python-maint .The whole team shares my concerns, as do other members of Core Services.

-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org

On 02. 04. 20 19:21, Aleksandra Fedorova wrote:

...

While benefiting the entire Fedora/RHEL/CentOS/EPEL ecosystem is certainly a good goal, I believe that doing this in a way that alienates a significant part of our packagers is a disservice to Fedora. The concerned packagers believe that Fedora is (and should remain) the upstream for RHEL, not RHEL itself. This might be shifting us to the undesirable mindset that Fedora is only a test bed for RHEL or a RHEL alpha version.

I literally addressed this part three times already here on the mailing list. And three times I got ignored, with someone posting the same concern again. If you'd like to have a conversation, please listen to the replies you get.

Hi Aleksandra, sorry for the late reply, I needed to take a break from this.

I am trying very hard to listen and to follow the entire thread. Forgive me if I've missed some replies or if I don't understand some properly. My vote is based on the change proposal as written. Could you please also address this in the proposal?

I'll reiterate again:

ELN is a tool to develop Fedora. Conditionals for ELN packages are going to be applied in those places where it makes sense and where it is approved by the Fedora packager.

The change proposal literally says that if a package fails to build in ELN, conditionals will be updated via a pull request that states a time limit. That does not imply approval.

Yes, we believe that adding the flexibility in Fedora deptrees and feature choices is beneficial to Fedora. It is Fedora flexibility, which can then be used by downstream, whatever the downstream would be. We are not going to enforce this vision, but we'd like to work with people who share it, to test if this can actually work.

I am all for flexibility. I am all for e.g. adding bconds to enable/disable certain things in Fedora instead of patching it out in downstreams.

However I believe that adding "if rhel, use prebuilt docs" is not adding any flexibility, it adds a layer of downstream specific "hacks" to our specs.

IIRC it was you, who used an upstream-downstream analogy between a software project packaged in Fedora and Fedora and between Fedora and ELN/RHEL/EL. Sorry if it was somebody else participating in this discussion. I will try to use that analogy here: We do not send patches to CPython that add "%ifdef FEDORA, use /usr/lib64" into their source files. That does not add flexibility. We send patches to CPython that add the "--withplatlib" option that we set in our specs to /usr/lib64.

The change proposal literally says that if I do not want to have %if's in my spec files the ELN SIG may provide a PR as described above or will discuss alternative approaches on an individual basis with me.

That is very vague. What's going to be in the PR if not conditionals? What are the alternate approaches for packagers who don't share this vision? It was repeatedly said in the recent e-mails here that ELN might fallback to regular rawhide builds in that case. Can this be documented in the proposal please?

You seem to describe this as "some packages are maintained by packagers who share the ELN vision and others be packagers who don't, so we'll work with the ones who do". But in my opinion, it is not that simple. One of my concern is drive-by contributors. What if the Fedora maintainer shares the ELN vision, but the drive-by contributor doesn't know anything about the ELN differences and they just want to provide some Fedora enhancement or bugfix, and it breaks the ELN build? Should such otherwise valuable contribution be rejected because they don't share the vision and this particular package is part of the "ELN-friendly set"?

We discard branching as the part of the ELN proposal, exactly because of the concern that Fedora infrastructure is going to be used by downstream maintainers to develop downstream packages. We DO NOT want that. That's why we say: if Fedora packager and downstream can not come up with the common solution on how to incorporate downstream changes in Fedora Rawhide, then downstream work can not and should not happen in Fedora (and as ELN is Fedora, it should not happen in ELN either).

From what part of the proposal do I deduce this particular approach? Is this your personal approach you will persuit as a member of the ELN SIG or something that's worth describing in the proposal?

Branching and dist git sync to downstream can and will happen, but on downstream terms and on downstream infrastructure. This work doesn't belong to Fedora, and therefore doesn't need to be discussed here in this change proposal.

That's fair.

Now you blame us for thing which we haven't proposed.

I am not blaming anyone for anything. I am providing my feedback and opinions on a change proposal as well as summarizing feedback by others. Can we please take a step back and not assume blaming? If my language implied blaming, it was not intended.

And it is hard to have a proper conversation about technical details, when the goal of the effort is repeatedly misunderstood and misinterpreted.

If something is repeatedly misunderstood and misinterpreted, maybe it is not described well? Or maybe the audience doesn't have all the context?

What are the exact goals of ELN? The proposal says "the main goal of ELN is to rebuild Fedora Rawhide as if it were RHEL." To me, that sounds like an "XY goal". That is https://en.wikipedia.org/wiki/XY_problem but imagine goals instead of problems. What is the problem this goal is trying to solve?

For example: If the problem is that branching RHEL from Fedora is painful because hundreds of %fedora/%rhel conditionals are broken every time, should there be a "Make conditionals used in Fedora specs future proof for next RHEL releases" goal? Or if the problem is that Fedora and RHEL are way too different, should there be a "Make Fedora and RHEL more similar to each other" goal? Or if the problem is that Fedora doesn't want AVX2 as the default, but we need to test this now, should there be a "Create a space where changes not yet ready for rawhide can happen" goal? Etc.

I realize that the goal might be a combination of those or a completely different one, so don't take those examples very literally. My point is that I don't understand "rebuild Fedora Rawhide as if it were RHEL" as a goal, but rather a transitive-goal to achieve something that you've "addressed three times already on the mailing list" yet I still cannot grasp it from the proposal.

Thanks for not giving up on me.

Dne 02. 04. 20 v 20:07 Stephen Gallagher napsal(a):

but I *did* acknowledge that we are going to incorporate the possibility of maintaining separate specs for ELN and Rawhide for any maintainer who absolutely wants to do more manual work.

You see, this is precisely the point where the disconnect is. I believe that the ELN branch is less work. Not because I as a RHEL downstream don't want to give back to Fedora or upstream, but because I want save Fedora and upstreams from or downstream problems (which are typically excessive dependencies). And this is not because I packaged one package here or there, that is because I maintain several hundreds packages in Fedora and a bit smaller amount (still close to hundred not counting their versions and variants) of packages in RHEL.

And this is just example from today why the conditionals are almost always wrong:

https://src.fedoraproject.org/rpms/rubygem-scruffy/c/ecdb3b762fef08eae8055d3...

What is wrong with this change? The only minor nit that the if branch is completely useless for ages. I don't remember anymore, why I thought the conditional should be there. May be I wanted to keep backward compatibility for some reason, but it appears to be wrong in any case. But the point is that if the condition was not there, it would save Björn from doing busy work (sorry Björn if you read it, I know you have fixed more then dozen packages at time, I appreciate that). And since the condition remains there, next time somebody will read it again and will struggle to understand what is the point while I as a original author have no clue anymore.

Vít

On Thu, Apr 2, 2020 at 3:02 PM Vít Ondruch vondruch@redhat.com wrote:

Dne 02. 04. 20 v 20:07 Stephen Gallagher napsal(a):

...

but I *did* acknowledge that we are going to incorporate the possibility of maintaining separate specs for ELN and Rawhide for any maintainer who absolutely wants to do more manual work.

You see, this is precisely the point where the disconnect is. I believe that the ELN branch is less work. Not because I as a RHEL downstream don't want to give back to Fedora or upstream, but because I want save Fedora and upstreams from or downstream problems (which are typically excessive dependencies). And this is not because I packaged one package here or there, that is because I maintain several hundreds packages in Fedora and a bit smaller amount (still close to hundred not counting their versions and variants) of packages in RHEL.

And having to manually perform a sync between those packages for every update is somehow less work than *checks notes* adding some conditionals once and then letting it get pulled from the master branch thereafter? I don't understand your logic here, I'm sorry.

And this is just example from today why the conditionals are almost always wrong:

https://src.fedoraproject.org/rpms/rubygem-scruffy/c/ecdb3b762fef08eae8055d3...

"People make mistakes, therefore we shouldn't try anything new." That's honestly what this sounds like. Conditionals are sometimes wrong, so don't ever use them?

I know this message is coming off sounding a bit flippant. I apologize for that, but tone is hard in an email. I understand that you have a personal preference against conditionalizing your spec files. As I said in my previous email: we are going to let you do that manual work if you want to. To me, it seems somewhat nonsensical, but I'm not going to continue to fight to change your mind.

Dne 02. 04. 20 v 21:38 Kalev Lember napsal(a):

On Thu, Apr 2, 2020 at 9:10 PM Stephen Gallagher <sgallagh@redhat.com mailto:sgallagh@redhat.com> wrote:

And having to manually perform a sync between those packages for every
update is somehow less work

There are two things:

1) Of course I don't expect I'll do it manually, but if I have to, then it is still better then having branches.

2) I see this as a `git rebase` where this works automatically.

You can call me naive ... but I can tell you that his works. However of course it depends on your strategy. If the work of common package looks like, e.g.:

My package is FTBFS due to several issues, so fixing this, I'll also do rebase. Later when finished, everything is one commit, then this might be problematic. But if there are several commits, e.g. a) fix first reason for FTBFS b) update the spec file to conform to the latest and greatest packaging standard c) rebase the package, the story is different.

And actually this is what we do. E.g. there is some security issue, I think twice how it should be fixed in Fedora so I can easily reuse the same patch in RHEL/RHSCL. And believe me, the simple patches such as security fix applies just fine from plain Fedora spec into SCL conventionalized spec.

I do this while preparing new Ruby release for a Rawhide in a branch, structuring commits so I can reuse them in Rawhide immediately.

Frankly, I expect that without branch, which will give you safe place, the ELN will be constantly broken and completely unusable.

than *checks notes* adding some
conditionals once and then letting it get pulled from the master
branch thereafter? I don't understand your logic here, I'm sorry.

For what it's worth, I agree with Stephen that conditionals are easier to maintain when we need to keep them working across rebases. I'd much prefer keeping a RHEL conditional in git master than having to manually go through each and every RHEL package after branching and adding back downstream changes.

This is continuous process. There is no branch point. That is the difference. You would need to keep the ELN branch up2date. IOW there won't be one time heroic to add some conditionals. That would be small continuous effort, keeping and eye when something is broken. But in this case, it is either fixing broken conditional, rebuilding Fedora packages, shipping them to users and then finally building also ELN package, while the branch would allow to not touch the Fedora package at all and fix just the broken conditional for ELN.

In my opinion, this doesn't scale at all -- it may work for people who maintain a small amount of packages and can keep track of what changes need to be made in RHEL, but not if someone is maintaining a large number of packages. (I am a package monkey for the GNOME stack with hundreds of packages, both in upstream Fedora and downstream RHEL) .

So how you envision this will work for Gnome? I am genuinely interested? You are doing the release not so often. It is typically big bang and update of everything. So you won't ship anything into Rawhide unless the ELN conditionals are correct (how you would ensure that)? Or you ship everything in Rawhide, then you start fixing the conditionals and ship again essentially the same content to Rawhide users after that? Both of the scenarios are big fail for Rawhide.

Or maybe you have different idea.

Speaking of updates of Ruby, my vision for Rawhide is to do everything as we did, e.g. keep maintaining development version of Ruby spec file in a branch, later merge into Rawhide and do mass rebuild in a side tag, merge it back (without any ELN conditionals). Then ELN will try to rebase everything (or if there are git symbolic-ref, there would not be needed anything), letting me know that I screwed something. I (or some ELN folks) will take a look, update the packages where the rebase failed, possibly adjusting the packages in a Rawhide.

Also writing this, I have realized, that there is one problem with the side tag and that is the commits into master branch. So although Rawhide keeps running just fine, ELN might be broken during this time. Depends what will actually drive the ELN rebuilds.

Vít

On Thu, Apr 2, 2020 at 2:07 pm, Stephen Gallagher sgallagh@redhat.com wrote:

We've collected the feedback in good faith, examined it and then identified shortcomings with it. For the sake of clarity in the Change Proposal, I've recorded that reasoning there.

I don't have any comment on the overall proposal, I just want to say it's pretty clear that you and Aleksandra are considering the feedback you've received, are discussing in the open, and are following our normal community processes for developing consensus and approving the change. This feels like an example of the *right* way to do a potentially-controversial change. In contrast to... you know, the other controversial thread we have right now. So thanks for that.

Downstream RHEL concerns *are* Fedora concerns. I cannot stress this enough: Fedora and Red Hat have a highly symbiotic relationship. The more RHEL succeeds, the more support Fedora gets from Red Hat. The more Fedora succeeds, the better the resulting RHEL product. It is disingenuous to imply that something that "addresses mainly a downstream RHEL concern using Fedora's resources" is a net-negative for Fedora.

Very true! We have a mutually-beneficial virtuous cycle here. Both Fedora and RHEL stand to benefit from changes that make RHEL development easier.

Michael

On 2020-04-02 20:07, Stephen Gallagher wrote:

On Thu, Apr 2, 2020 at 12:56 PM Miro Hrončok mhroncok@redhat.com wrote:

...

The change proposal received overly negative feedback by the packager community as represented both by RHEL¹ and non-RHEL maintainers. Despite being reworked several times, none of this feedback was reflected in the proposal, only new reasons why this is going to be done the original way were added. It seems that feedback is collected not to find the best technical solution, but rather to find ways to justify a solution that's already decided.

This is needlessly antagonistic, Miro. We've collected the feedback in good faith, examined it and then identified shortcomings with it. For the sake of clarity in the Change Proposal, I've recorded that reasoning there.

...

Key questions in the *Detailed Description* remain "out of scope of ELN" or not answered clearly.

If something is not clear, please constructively offer that information. I've been doing my best to rephrase and clarify anything that has come up. Anything remaining that is "out of scope of ELN" is literally just that. ELN's scope is largely "Make Fedora Rawhide more useful to downstream so that downstream developers will work there instead of internally".

# What if packages don't build on ELN?

The question isn't actually answered. Instead, the proposal answers *how* packages will fail to build in ELN.

# If a package fails to build on ELN, what will happen?

What will the time limit be? What exactly happens is a maintainer rejects the pull request?

# What if there is a new upstream feature RHEL wants in a package, how will that go in?

Why is this not in scope? We're bringing RHEL development closer to Fedora development. Non-Red Hatters don't know how a feature gets into RHEL, and I don't blame them if they think this will affect their workflow. Will it? How?

# What if I do not want to have %if's in my spec files?

What happens if ELN SIG cannot find a solution the maintainer is comfortable with?

# What if I do not want to have %if's in my spec files, but I want to see how changes show up in RHEL?

Sorry, but the answer reminds me of Modularity promises that the missing pieces will be ready in the future. What will the maintainer actually be expected to do in this case?

...

The proposal should address the impact on all major packaging styles, and while one side of the spectrum (packagers preferring single-spec with conditionals) is covered, there are very few concrete details on the other (packagers interested in simple spec files or completely uninterested in RHEL). The affected packagers are concerned that the current proposal does not in fact benefit Fedora (to an extent that would justify the disruptions), but rather addresses mainly a downstream RHEL concern using Fedora's resources.

This is a great example of the Nirvana Fallacy. Essentially, you are arguing that improvements for one group is not acceptable unless it improves things for every other group too.

It doesn't have to *improve* things for the other group, but if not, it should clearly acknowledge that it makes things worse (or the same), and say how. Otherwise that group will justifiably feel excluded.

Say a new package is added to RHEL, which was previously only in Fedora. The packager doesn't want RHEL conditionals in the spec. The change doesn't make sense upstream or in Fedora (for example, the crypto backend needs to be replaced to comply with some regulation). Without the change, the package (and anything depending on it) cannot be built in ELN. As I read the proposal, ELN will work with the packager and try to find a good solution. However, the discussion might be under pressure of RHEL guidelines.

What *actually* happens in this worst case? Will the macros be forced into the package? (If yes, please say it explicitly, so we can discuss that! If not, hooray -- alse say that explicitly!)

Even if the worst case scenatio is very unlikely, it would help thinking about the not-ideal-but-not-worst cases as well.

Downstream RHEL concerns *are* Fedora concerns. I cannot stress this enough: Fedora and Red Hat have a highly symbiotic relationship. The more RHEL succeeds, the more support Fedora gets from Red Hat. The more Fedora succeeds, the better the resulting RHEL product. It is disingenuous to imply that something that "addresses mainly a downstream RHEL concern using Fedora's resources" is a net-negative for Fedora.

Yes, that is true! The question is, does the goal justify the means? And even before that, what exactly are the means (specifically, in terms of limiting packager autonomy)?

...

While benefiting the entire Fedora/RHEL/CentOS/EPEL ecosystem is certainly a good goal, I believe that doing this in a way that alienates a significant part of our packagers is a disservice to Fedora. The concerned packagers believe that Fedora is (and should remain) the upstream for RHEL, not RHEL itself. This might be shifting us to the undesirable mindset that Fedora is only a test bed for RHEL or a RHEL alpha version.

I think you're missing a major point here. The purpose of ELN is for *that* to be the RHEL test-bed/Alpha. But we want it to stay as close as possible to Fedora Rawhide because that is how we solve two problems: 1) lack of consistent involvement by Red Hat engineers in Fedora and 2) eliminate the long lag-time between when features land in Fedora and when someone evaluates them for RHEL.

...

For me this feels like a step back to the [discontinued Fedora Core](https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00091.html), where the packages that were included in RHEL could only be maintained by their RHEL maintainers. Fedora relies on the contributions of non-RHEL developers — and those often have little interest in downstream work. If we alienate the community contributors, it will ultimately lead to a worse RHEL down the road.

I have no idea where you're getting this from, as we've tried to be very clear from the start that we want to make the pipeline of Fedora -> RHEL much more clear. We're not changing access permissions on these repositories. We're going to be opening up some of the "secret sauce" so that more of the community can see what we are testing. They will have greater insight into the potential usage of their packages.

...

For the stated reasons I am *-1 for this change in its current form*.

That is your privilege as a member of FESCo. As I've said, however, I think you've misunderstood the situation.

...

As said on the mailing list, I'd appreciate if you take the feedback provided by the packagers more seriously and adjust the proposal accordingly.

I have read and responded to the feedback as best I know how. Please do not confuse "I disagree and here are my reasons" with not listening to the feedback.

Lastly, I don't know if you reread the latest updates (that I made around three hours ago to the Change Proposal), but I *did* acknowledge that we are going to incorporate the possibility of maintaining separate specs for ELN and Rawhide for any maintainer who absolutely wants to do more manual work. The exact mechanism is going to at least partly depend on the results of the dist-git forge move, so I haven't incorporated that into the proposal. Functionally, it will be very similar to maintaining a separate branch, though. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org

On 2020-04-03 14:43, Aleksandra Fedorova wrote:

On Fri, Apr 3, 2020 at 11:59 AM Petr Viktorin pviktori@redhat.com wrote:

...

On 2020-04-02 20:07, Stephen Gallagher wrote:

...

On Thu, Apr 2, 2020 at 12:56 PM Miro Hrončok mhroncok@redhat.com wrote:

...

The change proposal received overly negative feedback by the packager community as represented both by RHEL¹ and non-RHEL maintainers. Despite being reworked several times, none of this feedback was reflected in the proposal, only new reasons why this is going to be done the original way were added. It seems that feedback is collected not to find the best technical solution, but rather to find ways to justify a solution that's already decided.

This is needlessly antagonistic, Miro. We've collected the feedback in good faith, examined it and then identified shortcomings with it. For the sake of clarity in the Change Proposal, I've recorded that reasoning there.

...

Key questions in the *Detailed Description* remain "out of scope of ELN" or not answered clearly.

If something is not clear, please constructively offer that information. I've been doing my best to rephrase and clarify anything that has come up. Anything remaining that is "out of scope of ELN" is literally just that. ELN's scope is largely "Make Fedora Rawhide more useful to downstream so that downstream developers will work there instead of internally".

# What if packages don't build on ELN?

The question isn't actually answered. Instead, the proposal answers *how* packages will fail to build in ELN.

These are linked topics.

ELN is a "build profile" applied to Fedora Rawhide sources. If we take a working Fedora Rawhide content and apply build profile to it, and it breaks, then there two reasons why it may break:

1. the content is different because of the conditional, and this

conditional is broken. So we fix it. 2) the build profile is different, then we fix the buildroot and build flags, and pungi config.

As we have a working baseline, it means that eventually if we reduce the number of differences we reach the working state. Once we have that working state we can start _adding_ differences again while keeping it in a working state.

...

# If a package fails to build on ELN, what will happen?

What will the time limit be? What exactly happens is a maintainer rejects the pull request?

# What if there is a new upstream feature RHEL wants in a package, how will that go in?

Why is this not in scope? We're bringing RHEL development closer to Fedora development. Non-Red Hatters don't know how a feature gets into RHEL, and I don't blame them if they think this will affect their workflow. Will it? How?

It is not a new thing which ELN changes. Red Hat developers have always been working with Fedora on changes. If feature makes sense to Fedora, it is not a matter of the ELN build, it is a matter of bringing it to Fedora Rawhide. ELN is not involved in this process.

OK, so would the following answer be correct? That is not in the scope of ELN. As in the past, the feature can be either added to Fedora (and ELN) on its own merits, or it can be added directly to RHEL without affecting Fedora (and ELN) at all.

...

# What if I do not want to have %if's in my spec files?

What happens if ELN SIG cannot find a solution the maintainer is comfortable with?

Again, we use raw Fedora Rawhide packages which work.

And if they don't work in ELN, it's up to the ELN SIG to make Rawhide packages work there. Right?

...

# What if I do not want to have %if's in my spec files, but I want to see how changes show up in RHEL?

Sorry, but the answer reminds me of Modularity promises that the missing pieces will be ready in the future. What will the maintainer actually be expected to do in this case?

In Fedora - nothing. ELN is not the answer to all the wishes. And we don't promise that we will ever cover this case in ELN. I don't see any similarities with Modularity here.

...

...

...

The proposal should address the impact on all major packaging styles, and while one side of the spectrum (packagers preferring single-spec with conditionals) is covered, there are very few concrete details on the other (packagers interested in simple spec files or completely uninterested in RHEL). The affected packagers are concerned that the current proposal does not in fact benefit Fedora (to an extent that would justify the disruptions), but rather addresses mainly a downstream RHEL concern using Fedora's resources.

This is a great example of the Nirvana Fallacy. Essentially, you are arguing that improvements for one group is not acceptable unless it improves things for every other group too.

It doesn't have to *improve* things for the other group, but if not, it should clearly acknowledge that it makes things worse (or the same), and say how. Otherwise that group will justifiably feel excluded.

Say a new package is added to RHEL, which was previously only in Fedora. The packager doesn't want RHEL conditionals in the spec. The change doesn't make sense upstream or in Fedora (for example, the crypto backend needs to be replaced to comply with some regulation). Without the change, the package (and anything depending on it) cannot be built in ELN.

Yes. It can not be build as ELN component, because ELN is about building Fedora components and this one is not one of them. It is a downstream trouble to deal with such cases. And we can discuss our options there. But it is not Fedora and not ELN.

...

As I read the proposal, ELN will work with the packager and try to find a good solution. However, the discussion might be under pressure of RHEL guidelines.

RHEL guidelines have no specific power in Fedora discussions. We want ELN to be part of Fedora, and ruled by Fedora. This is why we submit it as Fedora change on Fedora infrastructure under Fedora policies. It doesn't mean that RHEL engineers can not talk to Fedora package maintainers. It is what open source developers do. And if you are Fedora packager anyone can approach you and suggest something. The ask here is to be open to the conversation, not necessarily to agree to it.

That makes sense.

...

What *actually* happens in this worst case? Will the macros be forced into the package? (If yes, please say it explicitly, so we can discuss that! If not, hooray -- alse say that explicitly!)

Nothing happens, really. As I said above, ELN build failures mean we stretched too far from Rawhide. When we hit one of those, we try to resolve it, but the ultimate fallback is always to get back closer to Rawhide configuration. If at some point ELN _becomes_ Fedora Rawhide, then it just stops as a project, because it doesn't make sense anymore.

But now it does. Because we have those differences, we have some of those rotten conditionals already, but also build flags and also different comps setup and compose config. It is not the specs alone, which we can change.

OK. So if a packager chooses to not care about ELN at all, leaving their package broken in ELN, the ELN SIG can talk to them but, ultimately, the packager is free to keep the package building in Rawhide only, and it's up to the ELN SIG to accomodate this. Is that right?

...

Even if the worst case scenatio is very unlikely, it would help thinking about the not-ideal-but-not-worst cases as well.

...

Downstream RHEL concerns *are* Fedora concerns. I cannot stress this enough: Fedora and Red Hat have a highly symbiotic relationship. The more RHEL succeeds, the more support Fedora gets from Red Hat. The more Fedora succeeds, the better the resulting RHEL product. It is disingenuous to imply that something that "addresses mainly a downstream RHEL concern using Fedora's resources" is a net-negative for Fedora.

Yes, that is true! The question is, does the goal justify the means? And even before that, what exactly are the means (specifically, in terms of limiting packager autonomy)?

There are no such limits proposed.

On Sat, Apr 4, 2020 at 8:31 PM Miro Hrončok mhroncok@redhat.com wrote:

To clarify: In Fedora Core/Extras the separation was by access permissions. Here it is based on knowledge and interests (or a lack thereof). People with zero knowledge and interest in "RHEL next" development will not be able to contribute to Fedora packages (as easy as before) because the sources are no longer only meant for Fedora.

It's a bit of a divergence, but...

From my foggy memories of my early days in Fedora (I started in the Fedora Project as a contributor officially in November 2007, but I had been lurking and poking around for two years prior), the Core/Extras split was slightly more complicated than that. It was true that were was an ACL split, but there was also a CVS tree split and the Fedora "Core" was maintained within the Red Hat Dist-CVS (though nobody called it that back then!) and synced out to the public CVS tree for Fedora Core. The transition to the merged CVS tree involved a lot of complicated work from a lot of different people, and ultimately enabled discontinuing the weird setup for Core with Fedora 7 and transitioning to the Koji build system and Bodhi update system, which we still use today. The transition to Dist-Git in 2009 would have been ridiculously more difficult if that hadn't happened already.

In case anyone wants to take a trip down memory lane: https://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge

----- Original Message -----

From: "Michael Catanzaro" mcatanzaro@gnome.org To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Monday, April 6, 2020 3:37:34 PM Subject: Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

On Sun, Apr 5, 2020 at 5:08 pm, Charalampos Stratakis cstratak@redhat.com wrote:

...

It is reasonable to provide a pull request to fix potential issues with ELN. What is not reasonable, is to impose a time limit and also expect the maintainers to follow up with that.

If allowing the ELN maintainers to fix build failures when the maintainer is unresponsive is "unreasonable," then I guess it will never build and this is all a pointless exercise. Setting up impossible requirements doesn't seem fair to the ELN developers.

I don't think I've mentioned the word 'unresponsive' anywhere, please don't move the goalposts here.

---

devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org

On 06. 04. 20 15:37, Michael Catanzaro wrote:

On Sun, Apr 5, 2020 at 5:08 pm, Charalampos Stratakis cstratak@redhat.com wrote:

...

It is reasonable to provide a pull request to fix potential issues with ELN. What is not reasonable, is to impose a time limit and also expect the maintainers to follow up with that.

If allowing the ELN maintainers to fix build failures when the maintainer is unresponsive is "unreasonable," then I guess it will never build and this is all a pointless exercise. Setting up impossible requirements doesn't seem fair to the ELN developers.

If the Fedora maintainers of packages that we plan to include in RHEL are not responsive, something is very broken and we need to fix that, not just merge the changes and go away.