More background: When I first installed Fedora Silverblue 39 on my computer last November, I was able to install the package using the same steps as listed above. Today(07/28/2024), this package got updated, and it seems everything is broken.
I’m not sure, but I bet that it has something to do with /usr/local
/usr/local is not actually a directory but a symlink to /var/usrlocal (you know, on Silverblue /usr is immutable).
If you compare the 2.4.3 spec file and the 2.5.0 one you will see that in the latest version it tries to install stuff in /usr/local, and ostree can’t handle that… I am just speculating, maybe we need a ostree expert.
In the meanwhile you could contact the copr maintainer and ask if it is really necessary to use /usr/local
Can such a script use a check function and install to /var/usrlocal/ instead? This would work, especially needed if these files are mutable, like the config files it seems to place there.
I actually think this is a pretty good idea, not just if the maintainer of this particular package will want to do that though. It seems the maintainer is just building this package for regular Fedora.
Hi, I’m aware of this issue. With latest version of keyd the default prefix has changed to /usr/local ([Maintainer Note] PREFIX changed to /usr/local · Issue #628 · rvaiya/keyd · GitHub) and maintainers were notified about this in advance. I’m actually using the Atomic variant and I’m currently troubleshooting this issue. Most likely I’ll go back to /usr prefix.
It should be fixed with version 2.5.0-3. Apologies for any issues this recent update might have caused. In the future please let me know if something isn’t working properly (I’ve stumbled upon this discussion purely on accident).
Thanks for your reply. Since you are also using an atomic variant, what would be the best way to install a package from COPR on an atomic Fedora variant?
I think your approach @snake is what we currently have. I have no knowledge about any other way that would allow COPR management. I might be wrong as I don’t track Atomic development that closely.
That said, I’ve created a simple wrapper script that I use for that purpose, you can find it in my dotfiles here. It allows me to enable/disable COPRs with simple command copr enable alternateved/keyd or copr disable alternateved/keyd.
I think we have at least 3 of those wrapper scripts now XD
the dnf copr command is pretty easy to implement, but official integration would require adding it to rpm-ostree.
I also have a wrapper script with support for almost all common tasks.
But this issue was not about the addition of the .repo file but the actual RPM. I also had an RPM fail poorly, the kernel-longterm package by kwizart that I would love to use