On Fri, May 14, 2021 at 10:53 AM Vít Ondruch <vondruch@xxxxxxxxxx> 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. > _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
