-
Notifications
You must be signed in to change notification settings - Fork 51
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
Move and rename package repos #2121
base: main
Are you sure you want to change the base?
Conversation
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 GitHub<#2121 (comment)>, or unsubscribe<https://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. |
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. |
This commit just moves all the unmodified files into their new locations. The interesting changes are in the next commit. Signed-off-by: James Le Cuirot <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
first pass
update_chroot
Outdated
@@ -103,17 +103,17 @@ EMERGE_DEFAULT_OPTS="--verbose --oneshot" | |||
source "/etc/portage/make.conf.user" | |||
EOF | |||
|
|||
sudo_clobber "/etc/portage/repos.conf/portage-stable.conf" <<EOF | |||
sudo_clobber "/etc/portage/repos.conf/gentoo-subset.conf" <<EOF |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't have to be split into separate files per repo definition, a single file with a stable name (flatcar.conf
) will do and it will be easier to handle changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Catalyst 4 sets them up this way, so it's easiest to follow suit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But we're regenerating/clobbering them here, so whatever catalyst did gets overwritten. Catalysts output/logic is opaque from the pov of these scripts, so I don't think its easiest to rely on it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're currently not deleting all the existing *.conf files though. We could do, but I think that would be impolite, especially given that we've been talking about custom overlays recently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the churn happening in this area, maybe deleting these conf files is the sane approach. /etc is part of the container image (same with /board/xxx/etc) so user modifications get lost by design.
Custom overlays will require a proper design and integration with scripts - perhaps the user will add an overlay in scripts/repos/....
and then this will be taken into account when generating the files, but either way - the configs are managed by scripts.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see at least 12 references for /mnt/host/source/src/scripts/repos -> maybe this can be added as a configuration path once in one file in a future patch.
Adding flatcar/flatcar-linux-infra#280 to the pile. |
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. I have removed code referencing /mnt/host/source/config rather than fix it up, as this is no location is no longer used anywhere. Signed-off-by: James Le Cuirot <[email protected]>
I'm putting this (and the associated PRs) on the ice for the time being. |
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.
changelog/
directory (user-facing change, bug fix, security fix, update)/boot
and/usr
size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.