On Fri, May 14, 2021 at 10:53 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
...
> Maintaining a separate branch for ELN requires us to do the
following things:
> * Create an `eln` branch for the package
> * Exclude the package from the Rawhide auto-rebuild
This is not necessary as long as `git pull --rebase` works.
I'm not sure what you mean here. What I was saying is that we need to
make sure that the auto-rebuild doesn't attempt to build the Rawhide
content in the ELN buildroot for this package.
>
> Maintaining an extra branch is more work for the packager, so it
> should be avoided whenever possible. Our goal with ELN is to maximize
> the value we provide to enterprise linux while minimizing the
> additional load that we put on maintainers.
Just FTR, you underestimate how much work this is going to save. Really.
I have just merged this PR [1] into ELN. This removes the build
dependency on texlive and while on it, it also removes dependency on
rubygem-stringex. You can check yourselves (and I suggest to take a look
at internal instance of RHEL9 content resolver) how big the dependency
chain is I assume I'll be able to remove 20+ packages and therefore the
Fedora maintainers won't be bothered. It will hopefully remove (at least
in my domain) the build order concerns.
So far, I have modified 4 packages in RHEL9 and therefore was able to
open requests for removal of ~25 packages. I call it good deal.
Oh, I absolutely understand that this will lead to dependency
trimming. However, such things are *also* possible via
conditionalizing the Rawhide specfile (which remains the recommended
approach, because it means you don't have to maintain a separate
branch).
>
> We may also look into the possibility of extending the auto-rebuilder
> to attempt a merge-and-scratch-build from Rawhide to the ELN branch,
> to reduce maintainer effort if they opt to maintain their package in
> the ELN branch manually.
>
>
> This is tracked in the ELN SIG as
https://github.com/fedora-eln/eln/issues/56
I am truly happy for this initiative.