Layered packages: best practices (install/update/remove)

Aurora is great. But unless you are total non-power user you are likely to need a piece of software that is not available through the Discover package installer.
For example, simply needing to connect to OneDrive is an epic adventure.

As a former Windows power user and software specialist/developer I feel quite lost in the LX universe.

I would like to understand and adhere to best practices for installing packages with rpm-ostree. I’m not even sure what the proper name for this is: layered packages? “sideloading”?
For clarity I will henceforth use “layered packages”. If this is wrong please do correct me.

I am especially concerned regarding updating - the packages themselves, but also what problems can arise from major system version updates and how to ensure the integrity of my Aurora system.

If I understand correctly, layered packages do not update automatically
My questions are:
How to install packages so that I am prompted to update them or so that they update automatically?
Is there a difference if the layered package is installed from Fedora repository or from somewhere else?

I found this post for Bazzite, but I am not sure it is applicable to Aurora:
Update/Remove .rpm

So, what would you advise is best practices for installing layered packages?


Tangent
I need to use Android platform tools and Android Debug Bridge (adb), and it has to be installed from Fedora repo with rpm ostree
And I sorely need to be able to connect to Google Drive and OneDrive
Google Drive connector is not working. Don’t even start me on OneDrive…
Setting up a web server and database seems equally daunting…
But that’s a different can of worms alltogether…

Maybe immutable systems are not my cup of tea after all?

What is LX? Linux? Blufin is even one step further that classical Linux, where you go to the Software application and install app or just use terminal with “dnf install <package>” on Fedora like distors. But Blufin idea is that operating system and applications should be separated and operating system should be as much as possible read-only (that is the name of “immutable”). In this case that is fundamentally different then Windows or classic Linux where ever program you install gets embed into existing system. This “immutable” principle in Blufin is way more like mobile phones are functioning where operating system is separate from applications.

Now, this looks like a mess… but it is because Linux is a freedom on choice. For any Universal Blue including Aurora there is a hierarchy of recommended way of installating packages which is the best described on Aurora’s Bazzite sister web page: first try to install application from flatpak (GUI is Software app), if flatpak does not exists follow second choice… if no second third etc.

I don’t use OpenDrive, but it may be installed inside distrobox container. Container is still separated from operating system. I have written detailed how-to in another similar thread and probably you can follow.

But… if you get to the bottom of Bazzite list, then you get to the “rpm-ostree”. Now you get to the Windows or classical Linux level where you mix applications and operating system. But in Aurora (any Universal Blue image actually) you get layers. First layer is you operating system and any application you install this way gets another layer on “top” of your operating system.

What happens when Aurora gets updated (like once per week):

  1. New Aurora image (operating system) gets downloaded.
  2. New Aurora image gets installed (after reboot)
  3. Any layered package gets installed on top of installed image (= operating system).

This is perfectly fine for software that required root (administrator) privileges like the one directly accessing disk or similar… but ordinary applications it is better to run them in distrobox container (like described in my how-to).

What can happen? If something fundamentally different appears in image update (less likely) then maybe layered packages will not be working well and you will need to uninstall them using rpm-ostree command and install it back.

and

It is long time I have used layered package, but I think it does get updated (unless package was installed directly from RPM file).

If package gets automatically updated it depends if package is installed from repository (like rpm-ostree install…) or you download RPM file and use “rpm” command (just like downloading exe file on Windows and install it - it will not get updated automatically).


Bottom line is, it is nothing wrong installing package as layered package (rpm-ostree install <package>), but… in this case you lose the idea of immutable operating system, because you have mixed applications with operating system and you get actually to the parity of classical Linux or Windows - you can get little bit less stable system, you know from the days of Windows every application you install can (in most cases doesn’t) make your system unstable.

Getting starting with Linux and jump directly to the Blufin is hard work, because in Blufin there are plenty of all kind of options… But don’t worry just ask the questions and someone will answer them or point you to the better forum if you have some specifics about some application (e.g. if you are asking about web browser features then it is better to ask them on web browser forum).

It depends. If you layer .RPMs, then they will not updated automatically. If the app receives an update, you will have to uninstall it, then install the updated version. If you layer packages from Fedora repos, or from COPR for example, they will be updated during your usual system update as they are shipped.

For example, I use Windscribe VPN. Their releases are available on Github. If I were to use rpm-ostree install https://github.com/Windscribe/Desktop-App/releases/download/v2.14.5/windscribe_2.14.5_guinea_pig_x86_64_fedora.rpm, I will not receive an update when 2.14.6 is released. I will have to uninstall 2.14.5, grab the 2.15.6 RPM link, then run rpm-ostree install again with the new URL.

At the same time, I have a need for waydroid, android-tools, and android-udev-rules. waydroid and android-tools are both available on regular Fedora repos, and android-udev-rules for example can be found packaged on COPR. In this case, I can enable the COPR repo on my local machine, then run rpm-ostree waydroid android-tools android-udev-rules. The packages will be available after rebooting. Then, if an update for any of the packages are released, I will receive them too during my next system update (or after, sometimes time shenanigans happen and causing delays)

If it’s essential for your daily activities, and layering is the solution that works and you’re comfortable with, I’d say go for it. It does have a quirk though; you will likely have to pay a bit of attention when major version upgrades are nearing (e.g., Fedora 41 → 42 or 42 → 43 in the future), since again, it’s best to reset layers before major upgrades happen to make sure nothing gets stuck in the middle. Then, after the version upgrades have been applied, you can layer them again. Sometimes infrastructural changes happen and system updates fail, even without a major version upgrade - in that case usually it’s best to first remove layered packages, run the update, then layer the packages back again.

It’s not at all a sin to layer packages, everyone has different needs and not all can be fulfilled through Flatpaks or Distrobox or brew or simple binaries. However, it’s also important to remember that layered packages aren’t shipped by the devs and maintainers, so support regarding them may not be guaranteed.

I believe atomic image devs and maintainers work to deliver a worry-free desktop experience and strive to deliver the same experience to all users (though of course, limitations caused by hardware, for example, can hinder that). However, there are specific operational needs that are difficult to fulfill without getting involved with the image itself (in your case, by layering packages). In this case, as long as the user understands this and the implications, there should be no problems or grievances. :wink:

2 Likes