Hello everyone. I’ve been using Fedora Silverblue for a day and found it extremely amazing. rpm-ostree is awesome. It was my dream to use a “git” styled package manager when I started Linux( fedora) seven years ago.
Anyways, so far I can see, rpm-ostree creates and switches an entirely new branch(Using git checkout?) whenever I install a new package into the system. Though I wished to have new commits instead of branches of a single deployment (on updates and new additions) with beta and rawhide branches(whenever available) so whenever something get’s wrong I can easily roll back to its previous state and sometimes git reset --hard too. Using rpm-ostree ex livefs is experimental but I’m using it because it’s extremely important. When I first install it, I got tired of rebooting.
Anyway, I have few questions.
How can I delete Mozilla Firefox? I don’t use Firefox and it’s my own personal opinion that I consider it as “linux bloatware” that comes pre-installed with every distributions I have heard of. There are lot of reasons why I call that but I don’t want to elaborate. Open source should be a matter of choice.
How can I enable automatic updates to my current deployment which is workstation desktop? The advantage of container/git based updates means anyone can roll back. I can’t find anything about it in man pages of rpm-ostree
There should be information in man rpm-ostreed-automatic, but looking on my own Silverblue system that man page is missing…which is wrong. Anyways, here’s the source to the man page:
Or you can review a post I did about enabling automatic updates; it might be a little out dated, but should give you a place to start:
As a side note, IIRC there are still some issues of changes to /etc being discarded if an upgrade has occurred but the system hasn’t been rebooted yet. Might be something to watch for if you go automatic (not sure if it still applies).
Why is Firefox included in the base image when it is available as a Flatpak?
Is the Flatpak not managed by Mozilla?
NOTE: on Flathub the Developer is listed as - and when you click on "See Details under “Publisher” you get a 404 so I have no way of verifying.
The version of Firefox in my base image is outdated yet the Flathub version was updated quickly. Putting the browser in the base image seem counter productive as Mozilla releases often now.
Hello @skewty, Welcome to the Forum!
AFAIK, Firefox on flathub is made from the latest stable of firefox and I believe is a Mozilla supported effort, but please verify that. It would be updated on Mozillas release cycle and not Fedora’s, and that will lead to discrepancies between the flatpak version and the version supplied on Silverblues base image. The incluson of Firefox in the base image was done prior to there being a flatpak’d version, although that is a bit of a red herring as there is also licensing to consider under Fedora’s model. When viewed through the lense of licensing, Firefox packaged to suit Fedora in the Fedora repo makes sense as the chosen alternative. Think of it like the fusion repos and workstation, they can be installed but they aren’t setup automatically since there is software in those repo’s that violate licensing requirements for Fedora packaging. The same approach has been taken with Flathub, since not every bit of SW on Flathub is compliant with Fedora Licensing requirements. Anyway, that leads to the obvious delay in getting the latest FF on the base system since Mozilla is not as strict as Fedora WRT licensing requirements. Sorry for the length, too much coffee.
Thanks for the reply, but that didn’t really address my question as to why Firefox is in the base image of SIlverblue and not just a Flatpak (from the Fedora Flatpak repository).
To include a GUI app in the base image goes against the goals of Silverblue (based on the slides they have been sharing at conferences).
Sorry, I don’t go to conferences so I didn’t get the slideshow presentation. I don’t remember reading any official documentation that stated including a GUI app in the base image went against the Goals of Silverblue. I thought the goals were to provide a Fedora Workstation that was container focused and employed a hybrid OS (rpm-ostree) to achieve the flexibility to layer packaging when required onto the base image, yet still provide the relative comfort of knowing you are able to rollback to a stable previous version in the event something doesn’t go quite right after you make a system change.
For graphical user interface applications, Flatpak is recommended, if the application is available as a flatpak.
[…]
Users can overlay the traditional packages by using the rpm-ostree install PACKAGE . But it should only be used when there is no other way. This is because when the new system images are pulled from the repository, the system image must be rebuilt every time it is altered to accommodate the layered packages, or packages that were removed from the base OS or replaced with a different version.
Fedora Silverblue comes with the default set of GUI applications that are part of the base OS. The team is working on porting them to Flatpaks so they can be distributed that way. As a benefit, the base OS will become smaller and easier to maintain and test, and users can modify their default installation more easily.
The Firefox rpm in the base image will probably stick around until it’s possible to ship preinstalled Flatpaks.
With all due respect to the author of the article, I think that the take on layering packages is a bit off. Especially based on the Silverblue documentation here. To quote from it
Silverblue’s immutable design is intended to make it more stable, less prone to bugs, and easier to test and develop. Finally, Silverblue’s immutable design also makes it an excellent platform for containerized apps as well as container-based software development. In each case, apps and containers are kept separate from the host system, improving stability and reliability.
and this bit here …
Silverblue has different options for installing software, compared with a standard Fedora Workstation (or other package-based Linux distributions). These include:
Flatpak apps: this is the primary way that (GUI) apps get installed on Silverblue.
Toolbox: Used primarily for CLI apps; development, debugging tools etc.
Package layering: The rpm-ostree tool used for host updates is a full hybrid image/package system. By default the system operates in pure image mode, but package layering is useful for things like libvirt, drivers, etc.
Layering is to be expected and was planned for, hence rpm-ostree, otherwise just use ostree on it’s own. What layering does is cause the new image to drift further from the core image the commit was created from. As a result of layering, every update will cause the creation of a new image which is based on the core image + layered packages. This will result in longer time than typical for updates of the system, and also may be viewed as making the commit less stable though that is uncertain.
If layering is a constant need for specific tools or packages normally found in the Workstation version, an issue should be raised with Team Silverblue for a feature addition.
Using 