Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Universal Blue Yum / DNF Repo #579

Open
noelmiller opened this issue May 15, 2024 · 4 comments
Open

Universal Blue Yum / DNF Repo #579

noelmiller opened this issue May 15, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@noelmiller
Copy link
Member

noelmiller commented May 15, 2024

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)
  1. 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

@noelmiller noelmiller assigned bsherman and unassigned bsherman May 15, 2024
@bigpod98
Copy link
Member

im willing to maintain the infra

@geoffreysmith

This comment was marked as off-topic.

@m2Giles
Copy link
Member

m2Giles commented Jul 2, 2024

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.

Copy link

dosubot bot commented Oct 31, 2024

Hi, @noelmiller. I'm helping the Main Repos team manage their backlog and am marking this issue as stale.

Your issue highlights the challenges of managing package dependencies across multiple repositories, which is affecting the build process. You suggested two potential solutions: creating a dedicated repository or collaborating with Fyra Labs. In the comments, bigpod98 offered to maintain the infrastructure, while geoffreysmith pointed out issues with version locking in rpm-ostree, and m2Giles proposed using scratch containers for better management.

Could you please let us know if this issue is still relevant to the latest version of the Main Repos repository? If it is, feel free to comment here to keep the discussion alive. Otherwise, you can close the issue yourself, or it will be automatically closed in 7 days. Thank you!

@dosubot dosubot bot added the stale Issue has not had recent activity or appears to be solved. Stale issues will be automatically closed label Oct 31, 2024
@castrojo castrojo added enhancement New feature or request and removed stale Issue has not had recent activity or appears to be solved. Stale issues will be automatically closed labels Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: No status
Development

No branches or pull requests

6 participants