Dne 14. 05. 21 v 16:29 Stephen Gallagher napsal(a):
In nearly all cases, we want the `rawhide` branch in dist-git to
provide the sources used to build packages for ELN. This ensures that
they are kept up to date and minimizes packager effort (since they do
not have to maintain an extra branch).
However, there are some cases where changes desired for ELN (and by
extension, enterprise linux) cannot go into Rawhide. A non-exhaustive
list:
* ELN wants to build without documentation, experimental features or
similar and the maintainer refuses to include `%{rhel}` conditionals
in the spec
* Fedora wants to use the latest version of an upstream, but ELN wants
to stay on LTS releases (e.g. Firefox)
* A package is retired in Rawhide but is needed as a dependency for a
package in ELN (usually as a result of the previous example)
* A package exists solely for use in ELN (e.g. lorax-templates-rhel)
I'm sure there are other good examples, but these are what I could
come up with off the top of my head. If you have other use-cases that
we need to consider, please suggest them.
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.
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.
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.
Vít
[1]
https://gitlab.com/redhat/centos-stream/rpms/rubygem-kramdown/-/merge_requests/1
_______________________________________________
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
