On Thu, Aug 5, 2021 at 11:51 AM Miro Hrončok <mhroncok@xxxxxxxxxx> 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@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
