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