Set up package definition links for release-monitoring.org

[davidjharder]

The release-monitoring project (Anitya) can include links to package definitions, but solus is not set up yet; see below.

We need to edit this file: https://forge.fedoraproject.org/infra/ansible/src/branch/main/roles/openshift-apps/release-monitoring/templates/anitya.toml#L152

But, we can't do simple string replacement because of our directory structure:

packages/n/nano
packages/py/python-wheel

Options:

• Link to github search
• Make some sort of reverse proxy for exactly this issue
• ?

[davidjharder]

ref. fedora-infra/anitya#2071

[clintre]

How do we want to handle this?

One option would be a simple router page say pkgview.getsol.us/packagename with simple logic...

Basically...

1. Check if it is a python package. If so set the folder path to py
2. If not get first letter and set the folder path to it
3. Then redirect to /github.com/getsolus/packages/tree/main/packages/folder path/packagename

Another option is the package landing page, like the demo I setup source which has similar logic but pulls the data from the package.yml and displays it in a clean manner with a link to the full package folder in the package repo.

[davidjharder]

IMO the router would be better. Mostly personal preference though

Also note, there are lib* paths too

[clintre]

Curious on the lib paths, as I am not as familiar with those. But we can work things like that in.

I whipped up a pure html/javascript test to do a redirect. There are two ways to do this. Both would have the same pattern for linking.
https://pkglinkwhatever.getsol.us/?pkg=<packagename> Which would parse and forward to the proper folder.

One is a blind forward, which means it does not check to see if it exists before forwarding. So the user could run into 404s. However this is minimized if we are only using it for release-monitoring.org. This is also faster since it is doing this blind.
You can test this method: https://solseek.org/test-blind.html?pkg=PyAudio

The second and more robust is that it uses the github api to make sure it exists first, then forwards or lets the user know there is an error. This is ideal overall. There is one catch. Since this would be an unauthenticated api it is limited to 60 per hour. However, that limit is tied to the IP, which, being javascript would be the user's ip not our host ip.
You can test this method: https://solseek.org/test-api.html?pkg=PyAudio

Source for both are in https://github.com/clintre/solus-package-view