As noted in the mailing list thread, dropping the devel package will cause anything that still depends on OpenSSL 1.1 to immediately FTBFS, preventing those packages from participating in mass rebuilds or delivering bug fixes or security updates. The situation is only slightly better than if OpenSSL 1.1 were retired entirely.

I support deprecating OpenSSL 1.1 in the usual sense to keep new packages from depending on it.

I do not, in general, support dropping devel packages as an intermediate step between the existing deprecation and retirement processes. An open distribution like Fedora should not be intentionally shipping packages that cannot be rebuilt from source.

I would also like to note that it has been only one release since OpenSSL 3.0 was introduced, and that porting packages from OpenSSL 1.1 without upstream support may be too much to expect of the maintainers of affected packages in Fedora.

I am sympathetic to the desire to stop supporting OpenSSL 1.1 as quickly as possible, and certainly not beyond its upstream EOL. I would suggest that a better process could look more like:

1. Promptly deprecate the package—in the usual Provides: deprecated() sense, which will prevent the introduction of any new dependent packages. This requires a Change proposal, but I believe it would be uncontroversial.
2. Identify remaining dependent packages and file bugzillas warning that OpenSSL 1.1 is nearing end of life. If possible, offer expert porting assistance or submit PRs. A tracker bug might be helpful.
3. File a follow-up Change proposal to retire the OpenSSL 1.1 compatibility package in a later Fedora release.

For this proposal, as written:

-1

There was a huge amount of feedback on the devel list but the proposal was not updated since the announcement. Consider me -1 procedurally. I'd like to know if the change owners are about to respond to the feedback by changing this proposal in any way, or if that's not planned.

@dbelyavs Do you plan to respond to the received feedback by changing this proposal in any way, or that's not planned?

I tend to limit the scope of the proposal and limit it mostly to "Provides: deprecated()", but we need to discuss it. Previous week was the vacation week in Czechia so we had no chance to discuss it.

This ticket will be discussed during today's FESCo meeting (2022-07-12 17:00 UTC in #fedora-meeting).

As is, without updates, still -1

@decathorpe I kindly ask to discuss also a limited version of the proposal

This topic was discussed during today's meeting:
https://meetbot.fedoraproject.org/fedora-meeting/2022-07-12/fesco.2022-07-12-17.00.log.html

We agreed to give Change owners more time to work on an updated proposal / make it concrete what a "limited version" would look like (+7, 0, -0).

Thank you!

@dbelyavs Any chance you could update the wiki page in time for tomorrow's meeting? It'd be nice to get this closed.

Thank you for the reminder! I've just updated the Wiki page.

Do you plan to add a specific date to the deprecated() provide?

Looks good to me now. Thanks for the update!

+1

Do you plan to add a specific date to the deprecated() provide?

ASAP when this change i approved.

I understand you would add the provide asap. But what would be the exact change?

Would it be:

Provides: deprecated()

Or would it be:

Provides: deprecated() = YYYYMMDD

And if it will have the date, what exact date that would be?

As we want to get rid of creating new packages depending on the openssl-compat package just now, I think we could use just

Provides: deprecated()

Please correct me if I'm wrong.

+1

As there are -1's here, lets visit this in the meeting tomorrow.

I plan to be present to vote in the meeting as well, but based on the updated wiki page and on https://pagure.io/fesco/issue/2821#comment-806752 :

+1

I'm also +1, based on the current Change page.

+1 given the updated Change proposal

Todays meeting: Approved ( +6, 0, 0)

Announced:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6VAM5N54Z4AJQ7XVYFSZZFC6QTG26P7H/