Re: RPM download page reports incorrect combinations - Mailing list pgsql-www

From Dave Page
Subject Re: RPM download page reports incorrect combinations
Date
Msg-id CA+OCxowiE2qsgeBJ5H0avg+aDLC0vtBhJS+P_sZchWS-Ppvwgw@mail.gmail.com
Whole thread Raw
In response to Re: RPM download page reports incorrect combinations  (Dave Page <dpage@pgadmin.org>)
List pgsql-www
Hi

On Thu, 21 Dec 2023 at 15:27, Dave Page <dpage@pgadmin.org> wrote:

On Thu, 21 Dec 2023 at 14:31, Jonathan S. Katz <jkatz@postgresql.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,
>>
>> https://www.postgresql.org/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.

Screenshot 2024-08-08 at 11.58.29.png

--
Dave Page
PostgreSQL: https://www.postgresql.org

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

Attachment

pgsql-www by date:

Previous
From: Célestin Matte
Date:
Subject: Re: [PATCHES] pglister: make organization name generic
Next
From: Christoph Berg
Date:
Subject: Rename "Hackers Emeritus" to "Past Major Contributors"