For generating custom images: the examples on github add COPRs and other third party repos:
However the repo file remains on the system after installation. Would it be good practice to clean up the repo files after package installation?
I’d like to gate all the changes on an image instead of having clients depend on other repos. Thanks!
Disclaimer: the OSTree Native Container stuff (AKA CoreOS Layering) is kind of new so my answer may be wrong.
I don’t think removing the repo file matters much, but I guess it depends on how the client is used. IIUC the only time a yum repo gets contacted is if you are using package layering client side (i.e. if someone had ran rpm-ostree install pkg on the running system).
If your client systems are just pulling from the container registry and they don’t have anything else layered (other than the OSTree baked in the container) then those systems won’t attempt to contact the yum repos.
Try it out and let me know what you find.
Right, I was thinking “if it’s getting an image then I shouldn’t need any of these” so I blew them all away in a VM to see what would happen:
[root@fedora yum.repos.d]# rpm-ostree update
note: automatic updates (stage) are enabled
Pulling manifest: ostree-unverified-image:docker://ghcr.io/ublue-os/base:latest
Checking out tree 2078a68... done
error: No enabled repositories
So it looks like it is indeed checking for it even if I don’t have anything layered.
Yeah. Either you do actually have a client side package layer that you don’t know about OR maybe there is a bug here.
If you could get this down to a minimal reproducer (using FCOS and one of the examples like the one you linked to above maybe) then that would be a good foundation for filing a bug/issue.
Ok, fresh CoreOS just says “No upgrade available” so I think that’s working as intended.
Time to start with a fresh silverblue VM and keep digging, I’ll report later!
Ok I think I found the issue on a clean VM!
When rebasing to quay.io/fedora-ostree-desktops/silverblue:37 it does its thing and then on reboot langpacks-en is layered, even though I didn’t explicitly add it. Removing all the repo files and trying an update results in an error.
However if I get rid of it with an rpm-ostree remove langpacks-en and then boot into that then an update says “No upgrade available” as expected.
Ok so I think the cause of the problem is rebasing to the quay.io silverblue image also layers langpacks-en, so I guess that’s the issue I should be reporting? (Which repo should I file this in?) Here’s the before and after:
State: idle
Deployments:
● ostree-unverified-registry:quay.io/fedora-ostree-desktops/silverblue:37
Digest: sha256:180bfff64e4f55cec7f79d5f62c673e669938716781d02734fc52e7ca76da967
Version: 37.20221229.0 (2022-12-30T01:00:08Z)
ostree-unverified-registry:quay.io/fedora-ostree-desktops/silverblue:37
Digest: sha256:180bfff64e4f55cec7f79d5f62c673e669938716781d02734fc52e7ca76da967
Version: 37.20221229.0 (2022-12-30T01:00:08Z)
LayeredPackages: langpacks-en
Odd. I wouldn’t have expected that. Maybe start over at Issues · fedora-silverblue/issue-tracker · GitHub
Ok same exact thing but the next day and everything rebased cleanly. Looks like I was on a self inflicted wild goose chase 
Deployments:
● ostree-unverified-registry:quay.io/fedora-ostree-desktops/silverblue:37
Digest: sha256:302b348d6570d94b5918307a865cc499cbe72f70e4856a3d0aaf9c08dfe62a94
Version: 37.20221231.0 (2022-12-31T14:30:43Z)
For the custom image repo files: I was able to confirm that the right packages landed on my image and that removing the repo files didn’t affect upgrades, everything was coming from the image.