Portal:Aeon/SoftwareInstall

Installing Software

Order of preference

It's recommended to install software in the following order of preference:

1. Flatpak
2. User Distrobox
3. Root Distrobox
4. Transactional Update

Flatpak

Flatpak apps are the preferred app distribution on Aeon. Flatpak and the Flathub store are enabled out of the box. Flatpak apps can be installed from Gnome Software or from the command line.

Distrobox

User Distrobox: distrobox is a tool that allows you to install any Linux distribution inside your terminal. You can enter a tumbleweed distrobox by running

 $ distrobox enter

For those who want to run GUI apps via a Distrobox can do so with a special export command so that apps feel more native and integrated with the system. Learn more about distrobox from their Github page and openSUSE's documentation.

Root Distrobox: distrobox also has a root mode for more specialized uses. For most use cases, user distrobox should be used. Learn more about root distrobox here.

Transactional Update

Aeon's underlying OS is deliberately minimal and should not be touched. However, it may be necessary to modify the underlying OS to install drivers, kernel modules, or certain VPN services. The `transactional-update` can be used to achieve this.

Aeon does not use zypper like openSUSE Tumbleweed or openSUSE Leap to install RPM packages and use them directly. Aeon uses transactional-update with zypper under the hood.

Most of the time, you should not need to use any of these commands interactively, as Aeon has automatic system updates via the transactional-update.service systemd service.

Example Commands

Commands for transactional-update are listed below. NOTE: Remember to reboot after the command is finished to see the changes!

• sudo transactional-update pkg install package_name install a rpm package
• sudo transactional-update pkg remove package_name remove an rpm package
• sudo transactional-update dup perform a system upgrade to the next release
• sudo transactional-update shell open a shell of the next snapshot (you can use zypper commands there). This should only be used for debugging purposes. Any bug report that can only be reproduced by using transactional-update shell is almost certain to be closed as WONTFIX.

Automatic Updates

By default transactional-update.timer handles automated system updates. This is set to daily which means that the task will be executed each day at 00:00:00.

In the event this might be at a time when the computer is off. In this case, the update will take place according to your transactional-update.timer settings (default value is 2h).

Some of the reasons why it may not be able to trigger an update could be:

• the computer was off
• the internet connection was disturbed - at time it is scheduled to.

This should not cause issues due to the way transactional-update works since the new packages are installed on a new snapshot for which to take effect you must reboot.

To track if transactional-update is able to upgrade, and run correctly you can use journalctl:

 $ sudo journalctl -u transactional-update.service 

You can also use journalctl with the -f flag to tail the logs in real time.

About Snapshots and Boot Behavior

By default, each transactional-update command produces a seperate, self-contained, snapshot that includes the changes requested by the transactional-update command.

This snapshot is BASED ON THE LAST KNOWN GOOD/BOOTED SNAPSHOT. The last of the snapshots produced by multiple transactional-update commands then takes effect when rebooting.

In other words sudo transactional-update pkg install $pkg1 followed by sudo transactional-update pkg install $pkg2 and then rebooting results in a system that has $pkg2 installed, but NOT $pkg1.

This is the expected, and sensible default behaviour - Aeon always wants to move from the last known good/booted snapshot to it's new state in the smallest, least disruptive way possible.

This is especially sensible when you think the default/expected behaviour is that Aeon updates itself automatically and most users should not be using transactional-update interactively at all. With transactional-update dup happening regularly in the background automatically, Aeon wants to make sure it's updating only to the latest clean system update state, not some weird hybrid of previous unbooted, unchecked, intermediate transactional-update dup that never got booted.

However, when ignoring this best practice and using transactional-update interactively, there may be times where you wish to run transactional-update against an existing unbooted, unknown-if-good snapshot.

For this use transactional-update --continue

Example:

sudo transactional-update pkg install $pkg1 followed by sudo transactional-update --continue pkg install $pkg2 will install $pkg1, then $pkg2 in the same snapshot that included $pkg1, marking that combined snapshot as the next boot target.

If problems occur however, there is no additional complexity figuring out whether it was $pkg1 or $pkg2 that broke anything, as users will need to rollback to the snapshot before $pkg1 was installed to return to the last known good state.