Hi all,
Per https://bugzilla.redhat.com/show_bug.cgi?id=2007031 -- openssl 3.x won't be added to RHEL 8, while updated packages are starting to need it.
It thus seems to be a good candidate for EPEL; the question is - are we allowed to maintain openssl3-* packages from the openssl srpm repo, or do we need to explicitly have an epel8-only (possibly F35 and F34 too, as they also don't have openssl3) 'openssl3' srpm repo?
The former would be easier to maintain as we can just rebase changes from Rawhide; the latter can be done but a bit trickier (we can document how to configure the openssl srpm repo to be a remote and merge changes).
It's surprisingly easy to have openssl3-* generated from openssl.spec - - but I want to check first to make sure this is OK before addressing some minor issues (e.g. I've not added conflicts with the original packages)
See the proof of concept, which builds fine on EPEL8: https://src.fedoraproject.org/fork/salimma/rpms/openssl/c/712fbe3ddd4ad02e55...
One worry I have is, epel* branches are normally blocked for packages that are part of RHEL. Would requesting an epel8 branch for openssl, to host an openssl.spec that would generate openssl3-* binary packages, be mistaken for an attempt to have openssl binary packages overriding the RHEL ones?
If we think this is OK, I'll finish up the work and open a PR against Rawhide; if the maintainers object, the changes are hopefully minimal enough we can just merge in changes going forward.
Thanks,
On Tue, Nov 9, 2021 at 7:38 PM Michel Alexandre Salim michel@michel-slm.name wrote:
Hi all,
Per https://bugzilla.redhat.com/show_bug.cgi?id=2007031 -- openssl 3.x won't be added to RHEL 8, while updated packages are starting to need it.
It thus seems to be a good candidate for EPEL; the question is - are we allowed to maintain openssl3-* packages from the openssl srpm repo, or do we need to explicitly have an epel8-only (possibly F35 and F34 too, as they also don't have openssl3) 'openssl3' srpm repo?
You'll need an openssl3 SRPM repo, but you could have commits synced from openssl from CentOS Stream 9.
On Tue, 2021-11-09 at 19:40 -0500, Neal Gompa wrote:
On Tue, Nov 9, 2021 at 7:38 PM Michel Alexandre Salim michel@michel-slm.name wrote:
Hi all,
Per https://bugzilla.redhat.com/show_bug.cgi?id=2007031%C2%A0-- openssl 3.x won't be added to RHEL 8, while updated packages are starting to need it.
It thus seems to be a good candidate for EPEL; the question is - are we allowed to maintain openssl3-* packages from the openssl srpm repo, or do we need to explicitly have an epel8-only (possibly F35 and F34 too, as they also don't have openssl3) 'openssl3' srpm repo?
You'll need an openssl3 SRPM repo, but you could have commits synced from openssl from CentOS Stream 9.
Ah, thanks. Is there a written policy disallowing renaming the package in the spec like I did? (I sense it might not be fully legitimate, but couldn't find anything).
Between syncing with Rawhide/Fedora and syncing with CS9, this will be interesting. CS9 *does* have openssl 3.x and we generally don't want to change this package too much, so if merging from a different package is needed for maintenance anyway, maybe CS9 is the better 'upstream' to use.
Will check at the EPEL meeting today before proceeding, thanks!
On Wed, Nov 10, 2021 at 8:38 AM Michel Alexandre Salim < michel@michel-slm.name> wrote:
On Tue, 2021-11-09 at 19:40 -0500, Neal Gompa wrote:
On Tue, Nov 9, 2021 at 7:38 PM Michel Alexandre Salim michel@michel-slm.name wrote:
Hi all,
Per https://bugzilla.redhat.com/show_bug.cgi?id=2007031 -- openssl 3.x won't be added to RHEL 8, while updated packages are starting to need it.
It thus seems to be a good candidate for EPEL; the question is - are we allowed to maintain openssl3-* packages from the openssl srpm repo, or do we need to explicitly have an epel8-only (possibly F35 and F34 too, as they also don't have openssl3) 'openssl3' srpm repo?
You'll need an openssl3 SRPM repo, but you could have commits synced from openssl from CentOS Stream 9.
Ah, thanks. Is there a written policy disallowing renaming the package in the spec like I did? (I sense it might not be fully legitimate, but couldn't find anything).
If I remember right, the spec file name needs to be in the format <dist-git-repo-name>.spec Thus, the spec file needs to be openssl3.spec, and thus you aren't really renaming it. :)
Someone can correct me if I'm wrong about the spec file naming, but I had to do that for my various <package>-epel spec file.
Between syncing with Rawhide/Fedora and syncing with CS9, this will be interesting. CS9 *does* have openssl 3.x and we generally don't want to change this package too much, so if merging from a different package is needed for maintenance anyway, maybe CS9 is the better 'upstream' to use.
Will check at the EPEL meeting today before proceeding, thanks!
Troy Dawson tdawson@redhat.com writes:
If I remember right, the spec file name needs to be in the format <dist-git-repo-name>.spec Thus, the spec file needs to be openssl3.spec, and thus you aren't really renaming it. :)
Yes, assuming that EPEL doesn't deviate:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_file_naming
I believe various tools will make the assumption that the specfile is named accordingly.
- J<
On Wed, 2021-11-10 at 13:10 -0600, Jason L Tibbitts III wrote:
Troy Dawson tdawson@redhat.com writes:
If I remember right, the spec file name needs to be in the format <dist-git-repo-name>.spec Thus, the spec file needs to be openssl3.spec, and thus you aren't really renaming it. :)
Yes, assuming that EPEL doesn't deviate:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_file_naming
I believe various tools will make the assumption that the specfile is named accordingly.
Yeah, let's avoid that minefield then. Mock seems happy with it but I'm not sure other tools will be.
Per the EPEL meeting, we're going with Neal's idea of basing this on the C9S spec rather than Rawhide; the intent will be to maintain this as an `openssl3` dist-git repo in Fedora but populate it with what I'm developing in https://gitlab.com/michel-slm/openssl3/-/commits/epel8 - so we can easily merge changes from C9S (which should be less of a moving target than Rawhide).
Given openssl3 is not in Fedora <= 35 it might be worth having this in Fedora 35 and below too, but let's start with EPEL
This shows the minimum changes needed to: - have openssl3-libs parallel installable with openssl-libs (tested in mock for x86_64) - mark the base, devel, and perl subpackages as conflicting - openssl3 and openssl both ship binaries in %{_bindir} - ditto with openssl3-perl and openssl-perl - openssl3-devel and openssl-devel both ship headers and includes with the same names
I had to exclude two config files in openssl3-libs that are also in openssl-libs; hopefully the old configs work with the new packages but I don't have an immediate test case.
If this looks sane to people, I can open a review request.
Thanks,
On Wed, 2021-11-10 at 15:48 -0800, Michel Alexandre Salim wrote:
This shows the minimum changes needed to:
- have openssl3-libs parallel installable with openssl-libs (tested in
mock for x86_64)
- mark the base, devel, and perl subpackages as conflicting
- openssl3 and openssl both ship binaries in %{_bindir} - ditto with openssl3-perl and openssl-perl - openssl3-devel and openssl-devel both ship headers and includes with the same names
And of course I forgot to paste in the commit: https://gitlab.com/michel-slm/openssl3/-/commit/3649e51f898dbe1d97695cd8aca2...
Thanks,
On Wed, Nov 10, 2021 at 03:50:44PM -0800, Michel Alexandre Salim wrote:
On Wed, 2021-11-10 at 15:48 -0800, Michel Alexandre Salim wrote:
This shows the minimum changes needed to:
- have openssl3-libs parallel installable with openssl-libs (tested in
mock for x86_64)
- mark the base, devel, and perl subpackages as conflicting
- openssl3 and openssl both ship binaries in %{_bindir} - ditto with openssl3-perl and openssl-perl - openssl3-devel and openssl-devel both ship headers and includes with the same names
And of course I forgot to paste in the commit: https://gitlab.com/michel-slm/openssl3/-/commit/3649e51f898dbe1d97695cd8aca2...
It's been 2 days, so I'm assuming I'm not doing anything insanely silly here. I've put up the package for review:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2022907
cc:ing Sahana who is driving the OpenSSL 3 migration in Fedora. Sahana, would it make sense to have this in Fedora 34 and 35 as well?
Best regards,
On Fri, Nov 12, 2021 at 03:21:35PM -0800, Michel Alexandre Salim wrote:
On Wed, Nov 10, 2021 at 03:50:44PM -0800, Michel Alexandre Salim wrote:
On Wed, 2021-11-10 at 15:48 -0800, Michel Alexandre Salim wrote:
This shows the minimum changes needed to:
- have openssl3-libs parallel installable with openssl-libs (tested in
mock for x86_64)
- mark the base, devel, and perl subpackages as conflicting
- openssl3 and openssl both ship binaries in %{_bindir} - ditto with openssl3-perl and openssl-perl - openssl3-devel and openssl-devel both ship headers and includes with the same names
And of course I forgot to paste in the commit: https://gitlab.com/michel-slm/openssl3/-/commit/3649e51f898dbe1d97695cd8aca2...
It's been 2 days, so I'm assuming I'm not doing anything insanely silly here. I've put up the package for review:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2022907
cc:ing Sahana who is driving the OpenSSL 3 migration in Fedora. Sahana, would it make sense to have this in Fedora 34 and 35 as well?
Best regards,
Updating to close the loop: openssl3 is landing in epel8!
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-ff6e908f7e
If anyone thinks they need this in Fedora 34 and 35, please let me know, otherwise I'll keep this EPEL8 only for now.
Thanks to Neal Gompa for all the review feedbacks, and everyone here for shooting down the original idea of doing this in the epel8 branch of the main openssl dist-git repo.
Best regards,
epel-devel@lists.fedoraproject.org