Simplify the Distribution Matrix for Linux Installers.

[karianna]

#499 kicked off a fun discussion in the PMC:

In essence, it isn't feasible for us to support the proliferation of Linux Distributions. However, we can through tooling and documentation make sure that folks who use a Linux distribution can easily install our packages.

As an example for Red Hat based distribution in our linux/Jenkinsfile we have something like:

'redhat' : [
            'rpm/centos/7',
            'rpm/rocky/8',
            'rpm/rhel/7',
            'rpm/rhel/8',
            'rpm/rhel/9',
            'rpm/fedora/35',
            'rpm/fedora/36',
            'rpm/oraclelinux/8',
            'rpm/amazonlinux/2',
            'rpm/oraclelinux/7'
        ],

Current thinking is to:

1. symlink everything that isn't rpm/rhel/ to their equivalent rpm/rhel/ to retain existing compatibility.

2. Update the website documentation on how to use the rpm/rhel/<version> for a user's specific Linux distro. This would include not "don't recommend the specific distro name", but use correct rhel/<version> instead, and provide a mapping table.

e.g. If you're using Fedora 36 then that maps to rhel version 8 (or whatever)

Originally posted by @karianna in https://github.com/adoptium/installer/issues/499#issuecomment-1183208458

[jerboaa]

It would be best to avoid rhel, IMO. Those RPMs are generic RPMs not specific to any distro in the above list (including rhel). Considering generic-centos-derivatives would be the chosen name, then we should publish to rpm/generic-centos-derivatives/1 and symlink others to it.

The version is really an generic-centos-derivatives version, since it currently works for the above list, but might change if at some point a dependency's name changes (or more generically we need to make a incompatible change to the RPM spec which produces RPMs for the above). So the version thing is future-proofing for that case.

[jerboaa]

I'd also like to point out that the binary RPMs currently getting pushed to rpm/rocky/8 and rpm/fedora/36 (or any other combination of the above list) are binary identical. So pushing them to those various folders makes little sense.

[netsandbox]

Any news regarding this topic?

[karianna]

Hasn't been discussed for awhile I'm afraid

[sxa]

Noting also that since we have a split between redhat and suse pacakges in the repository we would not be able to completely unify these.