First of all I would like to thank you for working on this project.
I have set up a VM with Bluefin LTS, just to tinker around with it.
I would like to enable Local Layering, as it is turned off by default. So far I have enabled it, but trying to overlay with rpm-ostree results in following error:
Checking out tree 900473b… done
Enabled rpm-md repositories: extras-common baseos appstream crb epel
Updating metadata for ‘epel’… done
error: Updating rpm-md repo ‘epel’: Failed to download gpg key for repo ‘epel’: Curl error (37): Could not read a file:// file for file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever_major [Couldn’t open file /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever_major]
Does this mean that it is not supported, or am I missing some Fedora-specific considerations here?
Perhaps it would help to understand what you are trying to accomplish.
In general, layering is done to install a couple of things that cannot be installed via brew, flatpak or distrobox. Or for things that really need to be close to the hardware.
But there are pretty severe consequences to the decision to layer. Namely, when dependencies conflict, you will need to back out your layered apps, re-perform the failing update and re-layer them. And you will be on your own in troubleshooting issues as they arise, because no other system will be like yours at that point.
So with that said, what is it you are attempting to layer?
EDIT:
And see these articles for why I am questioning you trying to pull from epel on Fedora:
I am aware of the consequences of package layering. I was trying to install libvirt for virt-manager. If I should consider changing my work distribution to be changed to an immutable LTS (in the future).
Instead of layering you can turn on development mode with: ujust devmode and select Enable. Now few GB dowload appears with dev image and you get virtualization out of the box.
But Universal Blue are not immutable OS offerings. They are atomic desktops - sort of in the middle. Not the kind of immutability that one might take advantage of in a classroom setting (for example) where the machine reverts to a known state upon reboot.
Rather it takes the stance that the host OS is off limits for modification deferring to delivery via bootc images. Anything done by a user (where even sysadmin is a type of user) should be done in container technology of some sort.
And as @red11 mentioned, a lot of the problems you are experiencing can be simply solved by switching to dev mode where many things you might be looking for are installed by default.
Then you have complete control over the bootc image you use (and deploy across an orginization). In the Containerfile you will not have the atomic desktop constraints; can work with copr’s as usual, etc.
I hope that helps.
I am excited for the journey you are on. Good luck!
I just ran into this myself trying to layer 1Password on LTS.
I retrieved the proper EPEL key from the Fedora repo, put it in the proper location, yet rpm-ostree doesn’t “see” it.
In my case, I would be fine with disabling the epel repo for this install (I think, as the rpm is either local, or on 1Password’s repo).
Jorge, I think you said you use 1Password, have you successfully layered it, or are you doing something else?
Sorry for the late reply, I had some busy days.
Devmode solves some of the issues (thx @red11), but it is not applicable to all use cases (e.g. JohnAtl).
Creating a whole bootc image to work around that sounds pretty overkill imo, but I will look into this if I find some spare time. Shouldn’t layering work ootb as this is a Silverblue fork? From what I have gathered from this thread so far is that EPEL is a separate package repository for RHEL derivatives. And from my previous error log the gpg key of it seems to be missing. Adding it back should fix my issue?
I want to clarify that Bluefin LTS is not a fork of a Silverblue and is not based on Fedora, but is instead based on CentOS Stream’s bootc image. EPEL is the repository for RHEL/CentOS.