Move and rename package repos
Move and rename package repos to repos/{gentoo-subset,flatcar-overlay}
Catalyst 4 has totally changed the way repositories are handled. It only works when the name of the directory containing the repository matches the configured name of that repository. We already renamed coreos to coreos-overlay accordingly, but we actually want entirely different names and more convenient locations too.
The repositories are now known as gentoo-subset and flatcar-overlay, and they live under scripts/repos. Using the same name as upstream Gentoo would have been problematic, and just "flatcar" would have looked awkward in documentation.
How to use
Simply enter a recent SDK and run sudo ./bootstrap_sdk. Note that this will automatically update the SDK container's Portage configuration, so you will need to recreate the container to go back to an older branch.
Testing done
I have built an SDK manually. I also now trigger a Jenkins build.
- [X] Changelog entries added in the respective
changelog/directory (user-facing change, bug fix, security fix, update) - [x] Inspected CI output for image differences:
/bootand/usrsize, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.
The two-phase Jenkins job against 4012.0.0 passed. I know there are conflicts, but the nature of this change means they will frequently appear, so I'll deal with them once this is reviewed.
Build action triggered: https://github.com/flatcar/scripts/actions/runs/10073858410
I just rebased this following the big package update. That really wasn't fun, so I would appreciate eyes on this soon.
It’s a good idea to get everyone to consider what the possible side effects or breakage due to this change could be before we merge it.
I can think of one that existing tests unfortunately didn’t catch: the emerge-gitclone helper used in the devcontainer does not handle the new repo paths - but the tests don’t exercise that sufficiently well (only binpkgs are tested). Could you check that? A new test case would be good for this.
From: James Le Cuirot @.> Sent: Tuesday, July 16, 2024 5:43:49 PM To: flatcar/scripts @.> Cc: Jeremi Piotrowski @.>; Review requested @.> Subject: Re: [flatcar/scripts] Move and rename package repos (PR #2121)
I just rebased this following the big package update. That really wasn't fun, so I would appreciate eyes on this soon.
— Reply to this email directly, view it on GitHubhttps://github.com/flatcar/scripts/pull/2121#issuecomment-2231267180, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABXINVUZOX3QTLJ4MWWG44DZMU5TLAVCNFSM6AAAAABK4YVHNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZRGI3DOMJYGA. You are receiving this because your review was requested.Message ID: @.***>
@chewi would it be possible to have two commits? one commit with the file renames and one commit with the actual logic needed to be reviewed? my browser bails on me after I try to scroll a little. And this way would be cleaner if we d need to point to the logic change.
It’s a good idea to get everyone to consider what the possible side effects or breakage due to this change could be before we merge it.
Thought of another one - the workflows that are being touched in this PR are used to file PRs against branches for all channels. The updated repo paths in the workflows will only work for main, unless this gets cherry-picked to all branches, which is risky.
Good idea with splitting the commit. That might make rebasing easier too. Pushed that now.
I was aware of emerge-gitclone, so I'll take a look at that. I was also looking at the flatcar-build-scripts. I hadn't realised the workflow scripts were shared though.
I had been trying to avoid creating symlinks, as I prefer to work through the breakage rather than stay in a semi-migrated state for ages. For these cases though, symlinks may be the simplest answer. We can remove them once we this has fully rotated through all the release channels. What about LTS releases though, are they also affected?
See flatcar/flatcar-build-scripts#160 for fixes to the build scripts. These should ideally be merged first. They are backwards-compatible, so they don't need to wait for this.
flatcar/flatcar-dev-util#19 will need to be merged first so that I can get a new version of emerge-gitclone into this PR.
Adding flatcar/flatcar-linux-infra#280 to the pile.
I'm putting this (and the associated PRs) on the ice for the time being.