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

Specify edition/version + source from the cli #193

Open
Amndeep7 opened this issue May 13, 2024 · 2 comments
Open

Specify edition/version + source from the cli #193

Amndeep7 opened this issue May 13, 2024 · 2 comments

Comments

@Amndeep7
Copy link

Doesn't seem like the interactive cli nor the cli proper provide the ability to specify which version of an OS to use. We are stuck with whatever is listed as the default (ex. https://github.com/fossable/goldboot/blob/master/goldboot/src/foundry/molds/arch_linux/mod.rs#L47-L54). This causes issues when the default is no longer available like in the case of that ArchLinux iso.

@cilki
Copy link
Member

cilki commented May 14, 2024

The ArchLinux ISO was supposed to default to latest, so I just fixed that.

For other OS's with stable releases, the problem may be that the process of building an image depends on what edition/version you're on. For example:

// Wait for preseed URL to be prompted
match self.edition {
DebianEdition::Bullseye => todo!(),
DebianEdition::Bookworm => wait_screen!("6ee7873098bceb5a2124db82dae6abdae214ce7e"),
DebianEdition::Trixie => todo!(),
DebianEdition::Sid => todo!(),
},

Most of those cases above probably end up being identical, but the install process could change in a future release. I haven't yet figured out a way to remove this maintenance headache other than recruiting lots of people to help :).

Maybe each OS can have an official maintainer responsible only for updating/deprecating the above snippet when an upstream release is made.

@Amndeep7
Copy link
Author

maintenance headache

A tool that I maintain also has to integrate with a variety of other tools and services. If you find out a general purpose solution to having integrations, let me know haha.

IMO you're probably stuck since this ends up being analogous to any other dependency that your software has, which are more or less guaranteed to bitrot underneath you.

Our two solutions are to test as thoroughly as we can, where we can, at least before a release gets pushed out (but ideally on every pr). Secondly, if someone's process downstream breaks, then they're likely to come complain to us which lets us know that we have to do some maintenance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants