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)
We have also GCC/OpenSSL cases, where we would like ELN to be ahead of
everything. Better to broke ELN at this stage where it already targets
RHEL10, then try this in RHEL.
Vít
* 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
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.
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
_______________________________________________
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
_______________________________________________
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
