Re: RPM download page reports incorrect combinations

Hi,

/download/linux/redhat/

claims RHEL 6 and RHEL7 supports latest PostgreSQL releases in the
community repo -- but we don't. RHEL 6 supports up to PostgreSQL 12, and
RHEL 7 supports up to PostgreSQL 15.

Any idea how we can fix it?

Regards,
--
Devrim Gündüz
Open Source Solution Architect, PostgreSQL Major Contributor
Twitter: @DevrimGunduz , @DevrimGunduzTR

ping :)

On Mon, 2023-11-13 at 11:32 +0000, Devrim Gündüz wrote:
>
> Hi,
>
> /download/linux/redhat/
>
> claims RHEL 6 and RHEL7 supports latest PostgreSQL releases in the
> community repo -- but we don't. RHEL 6 supports up to PostgreSQL 12,
> and
> RHEL 7 supports up to PostgreSQL 15.
>
> Any idea how we can fix it?
>
> Regards,

--
Devrim Gündüz
Open Source Solution Architect, PostgreSQL Major Contributor
Twitter: @DevrimGunduz , @DevrimGunduzTR

On 12/21/23 5:35 AM, Devrim Gündüz wrote:
>
> ping :)
>
> On Mon, 2023-11-13 at 11:32 +0000, Devrim Gündüz wrote:
>>
>> Hi,
>>
>> /download/linux/redhat/
>>
>> claims RHEL 6 and RHEL7 supports latest PostgreSQL releases in the
>> community repo -- but we don't. RHEL 6 supports up to PostgreSQL 12,
>> and
>> RHEL 7 supports up to PostgreSQL 15.
>>
>> Any idea how we can fix it?

I believe there's a JSON file stored on the server that can control
this. Unfortunately I don't have access to the server to do that, so
Magnus would have to do that.

Thanks,

Jonathan

On Thu, 21 Dec 2023 at 14:31, Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:

> On 12/21/23 5:35 AM, Devrim Gündüz wrote:
> >
> > ping :)
> >
> > On Mon, 2023-11-13 at 11:32 +0000, Devrim Gündüz wrote:
> >>
> >> Hi,
> >>
> >> /download/linux/redhat/
> >>
> >> claims RHEL 6 and RHEL7 supports latest PostgreSQL releases in the
> >> community repo -- but we don't. RHEL 6 supports up to PostgreSQL 12,
> >> and
> >> RHEL 7 supports up to PostgreSQL 15.
> >>
> >> Any idea how we can fix it?
>
> I believe there's a JSON file stored on the server that can control
> this. Unfortunately I don't have access to the server to do that, so
> Magnus would have to do that.

There is, but the backend and front end parts all assume that every branch
is supported on every distro/distro version. We’ll need to build in the
ability to specify a support matrix.

>

Hi

On Thu, 21 Dec 2023 at 15:27, Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
> On Thu, 21 Dec 2023 at 14:31, Jonathan S. Katz <jkatz(at)postgresql(dot)org>
> wrote:
>
>> On 12/21/23 5:35 AM, Devrim Gündüz wrote:
>> >
>> > ping :)
>> >
>> > On Mon, 2023-11-13 at 11:32 +0000, Devrim Gündüz wrote:
>> >>
>> >> Hi,
>> >>
>> >> /download/linux/redhat/
>> >>
>> >> claims RHEL 6 and RHEL7 supports latest PostgreSQL releases in the
>> >> community repo -- but we don't. RHEL 6 supports up to PostgreSQL 12,
>> >> and
>> >> RHEL 7 supports up to PostgreSQL 15.
>> >>
>> >> Any idea how we can fix it?
>>
>> I believe there's a JSON file stored on the server that can control
>> this. Unfortunately I don't have access to the server to do that, so
>> Magnus would have to do that.
>
>
> There is, but the backend and front end parts all assume that every branch
> is supported on every distro/distro version. We’ll need to build in the
> ability to specify a support matrix.
>
>>
OK, so I finally got around to attempting to fix this. There are a number
of issues to consider:

1) The backend part (spider_yum.py) is modified to produce output such as
this:

./spider_yum.py /var/ftp/pub/repos/yum
https://wrigleys.postgresql.org/download/uploadyum/
{"platforms": {"EL-9": [{"arch": "aarch64", "versions": ["16", "15", "14",
"13", "12"]}, {"arch": "x86_64", "versions": ["16", "15", "14", "13",
"12"]}], "EL-6": [{"arch": "x86_64", "versions": ["12", "11", "10", "96",
"95", "94"]}, {"arch": "i386", "versions": ["12", "11", "10", "96", "95",
"94"]}], "EL-7": [{"arch": "ppc64le", "versions": ["15", "14", "13",
"12"]}, {"arch": "x86_64", "versions": ["15", "14", "13", "12"]}, {"arch":
"aarch64", "versions": ["15", "14", "13", "12"]}], "EL-8": [{"arch":
"x86_64", "versions": ["16", "15", "14", "13", "12"]}, {"arch": "ppc64le",
"versions": ["16", "15", "14", "13", "12"]}, {"arch": "aarch64",
"versions": ["16", "15", "14", "13", "12"]}], "F-40": [{"arch": "x86_64",
"versions": ["16", "15", "14", "13", "12"]}], "F-38": [{"arch": "x86_64",
"versions": ["16", "15", "14", "13", "12"]}], "F-39": [{"arch": "x86_64",
"versions": ["16", "15", "14", "13", "12"]}]}}

It gets the platforms and the architectures as it previously did, however
it now also finds the latest repo RPM for each platform/architecture
combination and extracts the supported versions from the .repo file that
would be installed. This seems to be the most robust way of doing this,
largely because inferring version support from the RPMs we might find on
the filesystem seems vulnerable to failure in various different potential
ways.

The downside of this is that it requires two new Python modules to be
installed (rpmfile and zstandard); we (the sysadmin team) would need to
figure out the best way to do that on ftpmaster.

2) The frontend part is re-jigged to request platform, architecture, and
desired PostgreSQL version in that order, with each combo box being
populated based on the previous selection. If any options are changed,
subsequent ones are cleared for reselection. The observant amongst the
audience may have noticed that we have some very old versions in the JSON
above, and may wonder what will happen with those. Firstly, I believe
Devrim is going to update the repo configs to remove them, however the code
does also filter out unsupported versions as well, so even if he didn't, it
wouldn't be a problem.

[image: Screenshot 2024-08-08 at 11.58.29.png]

--
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL:
EDB: https://www.enterprisedb.com

PGDay UK 2024, 11th September, London: https://2024.pgday.uk/