It’s something we might see with the next EL release cycle. rpm-ostree has treefiles complete with the option for (experimental) lockfiles. There’s already config files for CentOS Stream to build CentOS Stream CoreOS, and those can be adapted for Alma. I think, atm, it’s more of an issue of general interest than technical limitations.
biribiri11
joined 8 months ago
It’d be dangerous if an installed app claimed to be something like sudo or bash. Even if a mechanism was created for flatpak apps to claim a single shell command, there is no centralized authority on all flatpak apps to vet them. If there was for flathub, and each uploaded package was checked, that still leaves every other non-flathub flatpak repo which must implement the same vetting. Because there’s no way to guarantee to do it safely, and because flatpak devs are unwilling to compromise, this is just what we get.
We might not be as lucky with the next one (or the ones in the past).
Or the ones in the present, for what that’s worth
I think that’s the issue here, but that might just be poor documentation
If anyone’s curious, here’s the RHBZ ticket listing the products RH has patched this in: https://bugzilla.redhat.com/show_bug.cgi?id=2262126
+1 to running whatever is packaged by your distro. For me, Fedora is rarely out of date. If worse comes to worse, you can always volunteer to become a packager and improve the ecosystem for everyone while fixing your own problems.
This is not April fools. The submitter did want to mess with people, though.
By the way, all Fedora packages are scanned with ClamAV as part of bodhi tests. Here’s the test matrix where xz 5.6.0 passed the scan, and would have allowed the exploit in for the F40 beta if it wasn’t obsoleted by another build where the vulnerability’s mechanism was disabled because it triggered valgrind failures in other software.
Sure, there’s more sophisticated AV software out there, but at the end of the day, the F40 beta was temporarily saved because of luck, the beta freeze period, and valgrind. The ecosystem as a whole was saved because “Jia Tan” wasn’t aware that making Postgres run slightly slower immediately raises alarm bells.
Fedora has a (disabled) present repo for Nvidia drivers from rpm fusion OOTB. Just open the hamburger in gnome software, go to software repositories and enable “RPM Fusion for Fedora - Nonfree - NVIDIA Driver”, and install akmod-nvidia as usual. For atomic desktops, you’ll want to use something like ublue, though, because rpm-ostree doesn’t support akmods afaik
To add onto this, if you really wanted to rebase and don’t want config file clashes, you can use ostree config-diff after rebasing to show what config files changed. You can also simply remove all the files in /etc, and on the next boot, ostree will re-populate it with the contents of /usr/etc in a three way merge. Just be sure to copy, at bare minimum, /etc/shadow, /etc/passwd, and /etc/fstab otherwise it’ll be very awkward when you try to boot again and your boot process fails because it doesn’t automatically mount your disks and you can’t login because you have no users. It’s kinda cool tho, that, at least for this very specific issue, those 3 files might not be needed if/when systemd-homed’s JSON User Records and Discoverable Partitions see wider adoption.
(Note: this is dumb and error prone, and you should absolutely do what the other commenter said)
Hopefully DNF5 gets in for F41, especially since it was supposed to get in as the default for the current release, F39. If anyone’s curious, here’s the vote for deferring: https://pagure.io/fesco/issue/3039
The reasoning for the upgrade: https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Benefit_to_Fedora
And the reasoning given by the DNF5 team for targeting F41 instead of F40: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EYE2JY537OM7GFW46EK7YIBLHJ52USAZ/ (though fesco also wanted to keep it in F41 to not disturb the mass branching from F40 to RHEL 10)
And some things that need fixing before it becomes default: https://github.com/rpm-software-management/dnf5/issues/1057
And some commands that will be/are implemented: https://github.com/rpm-software-management/dnf5/issues/429
Personally, I just hope DNF4’s (what)provides comes back in full.
I’d really like it if Fedora didn’t discourage packaging static libs, but still discouraged building packages with static libs. It’d be nice to have them for development purposes.
I also wish they made “third party” software a bit easier to access in their installer and distro as a whole. The option to enable Nvidia drivers is buried, and even though flathub is now unrestricted when toggled in the installer, it’s not the first priority when prompted for software to install in gnome software.
A longer support cycle with less releases would also be nice, but would defeat the purpose of the distro. I guess it’d make more sense if CentOS Stream released more frequently and with more packages available in EPEL, similar to Ubuntu.