transactional-update, the application to update read-only systems such as openSUSE MicroOS and openSUSE Kubic and the Transactional Server installations of openSUSE Leap, openSUSE Tumbleweed and SUSE Linux Enterprise Server, evolved from a POC to a fully fledged solution - and is currently completely written in Bash. This has been working really well in the past, but is gradually reaching its limits, especially when thinking about supporting additional file systems or ports to other Linux distributions - yes, we have a huge interest in other distributions adopting our technology.

A C++ version would simplify those abstractions, but would it also make maintenance of the complete application easier? Check that as part of a POC and refresh C++ knowledge on the way there.

Potential caveats:

  • How is the selfupdate supposed to work when the application is compiled against a newer version of the core libraries?

Looking for hackers with the skills:


This project is part of:

Hack Week 19


  • Pharaoh_Atem
    9 months ago by Pharaoh_Atem | Reply

    I'd love to see a DNF-based port of this working on Fedora and openSUSE. add-emoji

    • fos
      9 months ago by fos | Reply

      No, I won't do the DNF based port myself add-emoji

      But if everything works out as expected you will get an application with a clear abstraction layer, so it should be easy to port it to any other package management system.

      (I wasn't able to work on this for the last two days due to an emergency at home, but I'll continue my personal Hack Week on Monday & Tuesday.)

    • fos
      8 months ago by fos | Reply

      I finally found the time to finish the POC, you can find it on Currently it's only barely possible to dist-upgrade a system using "dup", but the core framework skeleton exists.

      The C++ version can be found in src.

      Implementing a different package manager / porting to a different system should be quite simple now: Just put your own implementation of the PackageManager class into the Packages directory and add an appropriate selection mechanism to PackageManager.cpp.

      Would this be something feasible for you? The alternative for now would be to keep the Bash implementation - and source a different file, which will contain the commands for the corresponding platform.

  • Pharaoh_Atem
    9 months ago by Pharaoh_Atem | Reply

    How is the selfupdate supposed to work when the application is compiled against a newer version of the core libraries?

    This should only be a problem if the package manager backend does something insane like use subprocesses to execute package management actions because the entire package manager code state isn't remaining in memory during the transaction.

Similar Projects

SMT solver for AWS Policy decisions in ceph RGW by abhishekl

Currently AWS uses a SMT solver to decide on pu...

HelenOS: <filesystem> of a down by jjindrak

During the previous Hackweek [0], I have succes...

Port some classic game to Linux by MDoucha

Let's pick some old classic game, reverse engin...