Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?

> On 4 Apr 2024, at 01:24, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Wed, Apr 03, 2024 at 01:38:50PM -0400, Tom Lane wrote:
>> The discussion we had last year concluded that we were OK with
>> dropping 1.0.1 support when RHEL6 goes out of extended support
>> (June 2024 per this thread, I didn't check it). Seems like we
>> should have the same policy for RHEL7. Also, calling Photon 3
>> dead because it went EOL three days ago seems over-hasty.
>
> Yeah. A bunch of users of Photon are VMware (or you could say
> Broadcom) product appliances, and I'd suspect that quite a lot of them
> rely on Photon 3 for their base OS image. Upgrading that stuff is not
> easy work in my experience because they need to cope with a bunch of
> embedded services.

That's true, but Photon3 won't package new major versions of PostgreSQL (the
latest RPM is 13.14). Anyone who builds v17 on Photon 3 on their own can just
as well be expected to build an updated OpenSSL no? This is equivalent to
RHEL7 which was discussed elsewhere in this thread.

If we are going to pin version dependencies for postgres X to available OS
release packages then it, IMHO, is reasonable to be for OS's that realistically
will package X (either by the vendor or a trusted external packager like PGDG).

It's possible, but not guaranteed, that RHEL8 ships v17 packages in ther
Application Streams Life Cycle model, they have packaged v15 so far with
retirement in 2028 so it seems likely there will be another package to retire
in 2029 when RHEL8 finally goes away (whether that will be v16 or v17 is also
speculation). Thus, pinning on 1.1.1 is grounded in packaging reality, even
though I sincerely hope that noone who isn't paying for support is running
1.1.1 now, let alone in 4 years from now.

--
Daniel Gustafsson