Hello people,

yes, you can shiver at the title: we have (are still, actually) done a new package management frontend. Why? Because KDE missed a great one. Maybe some of you using Arch Linux will recognize the name Shaman: it is the default package manager frontend in Chakra, and my very first project with Qt. As such, it has grown quite old, and it’s showing the limits of my early programming skills, which made it almost unmaintainable by now. So me and Lukas (boom1992) decided to take it on a whirl and rewriting it from the ground up, with a more ambitious goal. We had some clear goals in mind:

It should have been extensible to any package management system and integrated with it

It should remain simple, and be extendable to the sky throughout plugins

It should be completely asynchronous to bring the user the best possible experience

It should be scriptable, to lower the barrier of the contributors and open up more possibilities to backends not in the C realm

There is one platform which actually makes this all possible, and it’s KDE 🙂 So we created Shaman 2. What is it?

Chapter 1: Shaman for Developers

Before being a package manager, it is a library. Think about it as the Solid or the Phonon of package management. This library provides an easy to use interface to implement frontends, and an abstraction layer for building plugins and backends. A backend is an interface to a package management system, such as apt, yum, packagekit, alpm, whatever. It is implemented as a static plugin that will be chosen upon build. People who need to implement a backend have to reimplement Shaman::BackendInterface and Shaman::Package, and make it work. It’s really easy to do: the current packagekit backend weights ~900 lines of code (and a lot of them are made of strings) and it’s almost feature complete.

Also, in the spirit of giving the backend developers the maximum flexibility, not forcing them into workarounds and getting the best possible performance/user experience ratio, you can implement delayed loading, custom caching of the information, custom progress reporting (soon), custom searching implementations and more. Shaman comes already preloaded with “Insane rockstar settings” (cit.), a backend for PackageKit and one for Aqpm (pacman), but we are looking forward to people who would like to port Shaman 100% natively on platforms not fully supported by PackageKit. For example, Shaman will support soon streaming transaction questions with custom widgets and creating scripted backends. Did you see any references to apt and/or debconf here? I did not.

At the moment all the code in Shaman runs unprivileged: in the near future, though, it will be given the possibility to create a backend with root privileges just by giving a switch to Shaman at compile time. Thanks to some PolicyKit+DBus magic, the backend (and only the backend) will be run privileged and will require authorization to perform any actions. You still have the option of running Shaman as root, but these days it’s really nonsense. You can also simply bypass such a possiblity and implement this straight into the backend (as Aqpm and PackageKit do), but this boils down to be your choice.

What is extremely cool about Shaman, though, is its plugin system. Almost any functionality can be implemented through plugin, from the GUI or the core side. In fact, the 2 main widgets of the Shaman interface are plugins as well. Plugins have a very important role in Shaman, and can also play an active part in transactions. Every plugin, in fact, can register some “Hook”, that can be run after and/or before a transaction. Pre transaction hooks have also the power of reporting fatal errors and aborting the upcoming transaction before it even starts. As you can imagine, there’s a lot of room for making Shaman fully integrated with the underlying distribution and perform some annoying tasks not belonging to the package management system. For example, what about a plugin that after a transaction checks if the kernel was upgraded, and in case rebuilds the VirtualBox kernel module?

Scripting support, as I told you, is a priority. Even if it’s not working right now due to constant changes in the API, it will be made ready as soon as we reach a semi-stable API, and it will use Kross. The basics are already there and ready, so it’s just a matter of time. Help welcome on this side, especially from some Kross masters around 🙂

The API is still unstable but it’s stabilizing as I write this. You know where to reach me, if you’re interested, we can have a chat and you can bug me with some questions 🙂 I look forward to plugin and backend developers

Chapter 2: Shaman for users

Anyway, what about the user interface? The user interface is meant to be non-modal when and where possible, simple & easy to use yet detailed, still remaining beautiful. How does it look like as of today? (Some screenshot here on Arch, some on Fedora, using Aqpm and PackageKit)

P.S.: The interface is changing by the minute and the default dialog sizes are much smaller than shown. Hey, this is a preview footage after all 😀

You might or might not have noticed some small differences in the PackageKit and Aqpm UI. This is because Shaman adapts its UI depending on the capabilities of the backend. So you will never be shown something your backend does not know about. Well, unless the backend developer is cheating, of course 🙂

Shaman implements also some neat stuff: for example, your queue is retained on exit. This means that if you mark some packages to be processed, then your girlfriend calls you and you realize being already 30 minutes late for your date, just don’t worry: close Shaman and turn off your PC: the next time you will start Shaman, it will automagically restore the last queue, which will be ready to be processed. There is also a transaction logger ready for you, so that you won’t lose any bit of history.

There is also security: Shaman is meant to be run as a standard user, using technologies such as PolicyKit and KAuth for granting authorizations for privileged actions.

And it installs, removes and upgrades your packages too!

Near future development

Shaman as the frontend is only the first product in our quest to provide a fully integrated and KDE branded experience for package management. Those of you who used/tried Chakra might have run into, and hopefully loved, Chase, the automatic update system. Chase will be improved and ported over to libshaman (not a lot of work actually), to provide automatic updates in a fully integrated way. And there is also some stuff boiling in our minds to bring to Plasma some of the package management: we are planning on a Plasmoid which will serve as a global visualizator for transactions done through libshaman, and will also provide some very basic package management functions. All the three tools (Automatic updates, plasma widget/engine, Shaman) will be tightly integrated and cooperating, instead of conflicting (just as it happens with Shaman 1 and Chase in Chakra right now), to provide users an easy and integrated way of managing their software.

That’s all, folks

And I sincerely hope I raised some interest 🙂 I am actually looking forward to distribution developers to get excited and use Shaman in their own distros. Up to now I have a VM for Fedora and Debian where Shaman runs great using the PackageKit backend.

The most important thing, is that Shaman is still not ready to be used. But for the brave souls and curious developers, playground/sysadmin/shaman is the place to be

Share this: Flattr

Twitter

Facebook

Like this: Like Loading... Related

Posted in Arch, Chakra, KDE, KDEmod, Linux, Qt, Shaman, Software

Tags: aqpm, Arch, debian, kde, Linux, package management, packagekit, pacman, policykit, Shaman, ubuntu, yum