Repository navigation
feat(recipes): extend the developer recipes to the new Linux guests - #99
Conversation
devtools and python-dev now declare almalinux, rocky and opensuse. The two dnf guests reuse the Fedora script, which is renamed install-rpm.sh to match what it covers. openSUSE gets its own script per recipe. Package names were checked on the guests themselves. AlmaLinux 9.8 resolves vim through vim-enhanced, so the rpm list needs no change. Leap 16 names the interpreter python313 and its pip python313-pip; both give /usr/bin/python3, /usr/bin/pip3 and a working venv. Signed-off-by: NovusEdge <novusedge0@gmail.com>
|
Warning Review limit reachedNext included review available in 17 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Team Run ID: 📒 Files selected for processing (7)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Live evidenceCandidate
Each row creates the VM with This is the first time these three guests have taken a cloud recipe at all. Before #97 the seed was a cloud-config-archive, and their cloud-init failed its init-local stage on it.
|
Closes #85. Depends on #97, which merged: a guest with recipes produces more
than one cloud-config document, and AlmaLinux and Rocky could not read the
archive stoat used to emit.
devtoolsandpython-devnow declarealmalinux,rockyandopensuse.The two dnf guests reuse the Fedora script. It is renamed
install-rpm.shtosay what it covers, matching what
python-devalready called its own.openSUSE gets one new script per recipe, because zypper names its interpreter
package differently.
Package names, checked on the guests
I booted AlmaLinux 9.8 and Leap 16.0 and asked their package managers rather
than assuming.
dnf list vimreports no match on AlmaLinux, which suggested the RPM listneeded changing.
dnf install vimresolves anyway:vim-enhancedprovides thename, and the transaction installs four packages. So the existing list works
unchanged on all three dnf guests, and the script says so in a comment.
Leap 16 names the interpreter for its version.
python313andpython313-pipinstall
python3-base, and in the guest:Both binaries the recipe looks for exist, and
python3 -m venvworks, so theshared venv logic needs no change.
Tests
TestBundledCommonDeveloperRecipeContractsnow expects all eight guests andchecks that every declared script resolves.
TestBundledPythonDevFallsBackWhenEscalationRefusescovers the three newmappings, so the escalation probe from #92 is exercised on them too.
Live evidence
Filled in when the matrix finishes.
Not in this change
The five
python-devinstallers differ by one package line and share about ahundred lines of venv and escalation logic. Collapsing them into one script
that switches on the guest is worth doing, and it is a bigger change than this
one.