bottlerocket-os / bottlerocket-os/twoliter
custom /etc/os-release
- Dominant language
- Rust
- Stars
- 34
- Forks
- 43
- Avg merge
- 11h 13m
- Merged PRs (30d)
- 16
Description
Currently we hardcode the contents of [/etc/os-release](https://github.com/bottlerocket-os/twoliter/blob/5c4c66055506e171600d077ac652f5bfe50316b1/twoliter/embedded/rpm2img#L373) based on build-related variables.
That locks downstream builds into specific outputs that they may not want; for example, `PRETTY_NAME` will always be something like "Bottlerocket x.y.z" even if the version isn't meaningful.
What I'd suggest instead is that:
1. if no `/etc/os-release` exists in the sys-root, we write the existing `os-release` as a file with unexpanded variables
2. then we apply `envsubst` to `/etc/os-release` in a second pass to fill in variables we want to replace
The URL fields should also be parameterized so that variable substitution works there too.
Contributor guide
Research direction
Read twoliter/embedded/rpm2img around the linked /etc/os-release generation. Check how the sys-root file is handled, then verify that an existing file is preserved, a missing file gets the unexpanded template, and variable substitution also covers the URL fields.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux, rust
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 48/100