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

Add support for specifying build time and run time package mirror URLs from the template config #646

Open
tomponline opened this issue Jun 17, 2022 · 5 comments
Labels
Feature New feature, not a bug

Comments

@tomponline
Copy link
Contributor

It would be good to provide the user the ability to specify URLs to be used for both build time download of packages and the URL used for package updates inside the built image. This would avoid needing to hard code them in the project's code itself when we need to use a specific mirror URL for our community image builds.

See #645 for more info

@monstermunchkin monstermunchkin added the Feature New feature, not a bug label Jun 13, 2023
@sona78
Copy link

sona78 commented Apr 2, 2024

I can add support for this if it has not been assigned

@Cashman0604
Copy link

Hello, I'm working with sona78 on this project and was wondering if there was more info on this issue. Are there specific files I should be looking into for this? Thanks!

@stgraber
Copy link
Member

So currently most images have two main URLs, one for where to fetch the initial image from and one for where to fetch the additional packages from. The former can usually be overridden through the "url" field in the "source" section. The latter depending on the package manager can be handled through the "repositories" sub-section (inside of "packages") or is just hardcoded.

On top of that, we'd likely find it quite useful to be able to specify build-time repositories as well as run-time repositories. The build-time ones being used while distrobuilder is running and then get removed and replaced by their run-time equivalent just before the image is generated.

I think a good first step would be to extend the repository syntax to allow marking entries as being only used for build time or for run time. We could do that with a presence field that would be set to one of always (default), build or runtime.

You could then test that by taking the Ubuntu example YAML and making it build with us.archive.ubuntu.com but then switch to archive.ubuntu.com in the final image as an example.

Once that works properly, the next step will be to go through the code and remove all the hacks we currently have around that, basically having everything rely on the new repository syntax.

A quick look through as showed me the following having hardcoded repository logic:

  • springdalelinux
  • centos
  • oraclelinux
  • almalinux
  • rocky

So essentially all of the Red Hat derivatives.

@Cashman0604
Copy link

Cashman0604 commented May 7, 2024

Hey, sadly I wasn't able to make considerable progress on this issue. I'll put the GitHub link and files/lines where the changes I made are. I worked on adding presence and the logic to handle it, but I was unable to test it due to the environment I was running, so I am not sure on its correctness. I still wanted to share it here in case it was helpful, but I didn't want to make a pull request since it could very well be wrong.

GitHub: https://github.com/sona78/distrobuilder
Changes:

  • docs/examples/ubuntu.yaml, line 246
  • Added Presence field to data structure
    • shared/definition.go line 113 and 118-123
  • Added logic check for Presence in ManageRepositories
    • managers/manager.go line 167
  • Add new variable in ManageRepositories, buildPhase, updated where function is called
    • main_incus.go line 209, main_lxc.go line 136, main.go line 402

Sorry I was unable to do more and I hope this is helpful!

@stgraber
Copy link
Member

stgraber commented May 7, 2024

Thanks for the notes and branch!

I've cleared the assignees on this one so others may take this over.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New feature, not a bug
Development

No branches or pull requests

5 participants