Create a dnf/yum repo for ublue hosted RPM specs, etc

[bsherman]

Background

There are several packages which we'd like to include in ublue, specifically kmods, which do not have an upstream akmod build, or do not have an RPMs built at all, even if the project provides a spec file.

Some examples:

• openrazer ( see Add openrazer #5 )
• xpad-noone ( see add xpad-noone and enable xone #26 )
• snapraid (for ucore) ( see request: investigate adding snapraid to ucore ucore#25 )

Beyond these which have no current solution, there are things we install which are in random COPR repos or in negativo17. Negativo17 seems reliable, but it's still an additional third party beyond rpmfusion, and random COPRs, well, it's like ubuntu-PPA land. If we don't know the maintainer, it's a gamble.

Goal

The goal is to provide a team ublue managed repo that:

1. at LEAST contains packages we can't get anywhere else (see examples above)
2. possibly contains packages which we currently get from random COPRs and other 3rd party repos
3. will NOT replace rpmfusion as it is a hard dependency at this point

Suggested Implementations

1. Host our own SPEC files

For any RPMs we need to build, we should host the spec files in our own github repo. This ensures control of what we are building and minimizes risk of a third party causing our RPMs to include any surprises.

I believe we could have a single repo rpm-specs (open to suggestions on name) with the various maintained spec files in it.

If we went all in on some of my suggestions for packages above it could include:

• openrazer.spec
• snapraid.spec
• xone.spec
• xpad-noone.spec
• etc

There may be subdirs for supporting files for each spec, or perhaps each spec goes into a distinct sub-dir by default.

2a. Github pages ublue-os rpm repo

One proposal, though a potentially janky approach, would involve having a dedicated github repo which is setup for github pages. This is distinct from rpm-specs, maybe call it rpm-repo.

Github actions in this repo would on whatever trigger, build the RPMs from rpm-specs, run a create-repo script that creates the yum repo metadata, and then commits resulting metadata and RPM binaries to the rpm-repo git repo such that the contents of the repo are available to use.

This is kinda janky, but it could possibly work.

The major pro is we don't need any extra user management, its just github.

The major con is we'll be reinventing some wheels and doing some janky stuff.

2b. ublue-os team COPR

Another proposal is to use a single COPR repo/project (insert proper terminology here). The spec files would still be hosted in a github rpm-specs repo as described above, but all building and repo hosting would be done in COPR.

There are webhooks and apis in COPR which should at least allow triggers of builds when changes are made to specs, or from other actions. Possibly the api could be used to add a new spec to the COPR.

The major pro here is COPR is specifically made to build and host RPMs.

The major con is user access/permissions management. We think it's single user. A possible workaround could be to manage limited access to a shared credential similar to how we already manage private key escrow for signing OCI images. Also, if we only need access to "setup" a build/project since webhooks could trigger rebuilds, this may be less of an issue than originally thought.

Feedback

I'd like some team feedback on this. A few of us have been thinking about this for months, but not really made progress. It becomes more of a blocker to progress as the days go on. Whichever path is taken will require some effort. No need to rush it, but it's good to be on the same page with goals and approach.

[EyeCantCU]

I believe we should go with a combination of 1 and 2b. Having a centralized place for spec files that we're using would be ideal. We can pull those into copr (since the infrastructure for that there is already excellent)

I understand there's a concern over shared access, but ideally, the package in copr just needs to be created and everything regarding maintenance after that would be done in a shared GitHub repository with an array of our spec files

I'm not saying 2a should be off the table. It would be cool and interesting to see something new there, but generally we already have the infrastructure we need without the jank