Universal Blue Yum / DNF Repo

[noelmiller]

Problem

Currently, we are pulling packages in from several different repositories and have minimal control on when packages are published, which can create skew in our build process.

Current Repos we are pulling in from:

1. RPM Fusion
2. Negativo
3. Copr

Potential Solutions

1. We create our own repository. There are several hosting options we can look into to accomplish this

Pros

• We have 100% control over the infrastructure
• We can look into locking it down to only be accessible by our github builders to minimize bandwidth cost

Cons

• We have infrastructure we need to manage now
• There is a cost associated with this (We have not found any free options in our research)

2. Look into partnering with a trusted provider. One that comes to mind is Fyra Labs: https://terra.fyralabs.com/

Pros

• Less burden on Ublue maintainers
• Likely be less or 0 cost

Cons

• We do not have 100% control of the infrastructure
• This would basically just be replacing negativo and rpm fusion with a different provider

Blocker

This a blocker for the following:

1. Bazzite has the desire to build it's own Kernel in Github, but we need a place to host the RPM packages
2. We can look at mirroring packages we depend on from RPM Fusion so we avoid breakage in our build pipeline

Feedback

I am looking for help and feedback on what we would like to do moving forward.

Main points of contention are:

1. Are there more potential solutions that I am not seeing to this problem?
2. If there is a monetary cost to doing this, how would we like to fund that?
3. Who would like to volunteer to be the primary maintainer of this new infrastructure?

Discord Thread

https://discord.com/channels/1072614816579063828/1240355645199486976

[bigpod98]

im willing to maintain the infra

[geoffreysmith]

There's a lot of drift and things like rpm-ostree refresh-md -f which is recommended in a lot of distros renables the version locking we're doing with some of these repos (version locking I mean disable to enable). So a lot of problems I've had required me to actually go into the source of rpm-ostree and bluefin's 100+ repositories and figure out the workarounds.

We're essentially breaking rpm-ostree and adding code in our build process to do so.

[m2Giles]

While a yum repo could be nice,

We have an additional possibility. Using scratch containers as a cache layer. We already do this with akmods and now have one for sync.

Depending on how we do tagging we could cache things appropriately and refer to them by a convenient name.