Hi everyone, No major progress on this task yet. I found out that the compat package needs some more fixing. I have more time in the coming days, so I should have an update soon hopefully.
Thank you, Regards, Sahana Prasad On Tue, Aug 10, 2021 at 7:57 PM Sahana Prasad <sah...@redhat.com> wrote: > > > On Thu, Aug 5, 2021 at 11:51 AM Miro Hrončok <mhron...@redhat.com> wrote: > >> On 05. 08. 21 11:03, Sahana Prasad wrote: >> > Hello everyone, >> > >> > As per the F36 schedule [1], rawhide starts F36 development on >> 2021-08-10. >> > I would like to bring in OpenSSL 3.0.0 [2] and the compat package [3] >> (along >> > with devel subpackage) into rawhide. >> > >> > I would like your opinion/suggestion on: >> > 1. Merging it and building it directly in rawhide. This will make >> OpenSSL 3.0.0 >> > available by default for immediate use in rawhide. >> > FTBFS bugs can be reported when there is a mass-rebuild as per [1] >> > versus >> > 2. Building it in a side-tag, adding all packages. Allowing the >> packages to >> > port and fix build failures >> > on the side-tag and finally merge the side-tag. FTBFS bugs can be >> reported >> > immediately. >> > >> > I have a slight preference for option 1: >> > >> > 1. As rawhide enables us to try out stuff like this. >> > 2. It is very early in the cycle to bring this change. >> > 3. Many upstream packages have been ported (or are in the process of >> porting) to >> > OpenSSL 3.0.0 >> > 4. Compat package (rebased to 1.1.1k version) is available with devel >> files. >> > >> > Although option 2 sounds more organized. >> > >> > But I could be missing some information/details. It would be nice to >> hear about >> > the experiences in the past and the preferred method by the community. >> >> Is it not probable that when the rebuilds happen gradually, weird stuff >> will >> happen? >> >> E.g. when: >> >> - python links to libopenssl 3 >> - libdnf or similar links to openssl 1.x >> >> An application, such as dnf, uses both. Can that be a problem? >> >> ---- >> >> To minimize unknown problems like this, I suggest to: >> >> 1. define a minimal acceptance criteria (e.g. "dnf works") >> 2. test (1) in copr, do not open the side tag until verified there >> 3. open a side tag >> 4. build openssl 3 in it >> 5. build as much packages linking to openssl in it as possible >> 6. verify (1), improvise until it is a success >> 7. merge the side tag >> 8. rebuild "misfits" once again (packages that succeeded in (5) but >> packagers >> rebuilt them in regular rawhide while the side tag was open) >> > > Hello everyone, > > I will follow these steps and start working on it tomorrow onwards. > > Thank you, > Regards, > Sahana Prasad > > >> This is different from your proposed side tag solution because there is >> no >> window left for "allowing the packages to port and fix build failures on >> the >> side-tag". Side tags are painful when opened for a long. >> >> IMHO This combines benefits of both of your solutions: >> >> - it is fast >> - it is more or less atomic, sans the packages that FTBFS >> >> -- >> Miro Hrončok >> -- >> Phone: +420777974800 >> IRC: mhroncok >> >>
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
