The new look for Muon package administration

Most Debian users are familiar with Synaptic [1], which has reliably served as a GTK-based, front-end package manager for years. Kubuntu users in particular have been utilizing its Qt clone for a long time. In terms of its usage and behavior, it is practically identical to Synaptic. The close connection to Apt, and some of its specialty libraries prevent adoption outside of Kubuntu. RPM-based distributions prefer to take a pass on the tool because of the age factor and the bad state of the maintenance for the gateway between Apt and RPM [2]. Nonetheless, the last two versions became the standard package management tool for Ubuntu, which is not always the case for preset tools.

New Maintainers

The main developers of KDE Frameworks 5 have taken on the issue of maintenance for Muon. The driver behind this effort is the Kubuntu developer Jonathan Thomas. He wants to see the Synaptic alternative Muon become a permanent part of the KDE portfolio, and it looks like this is what has happened. In the meantime, the program carries the version number 5.3.2.

Instead of being directly based on the terminal program Apt, PackageKit [3] has assumed the task of translating program system calls in such a way that the package manager in use can understand them. There are suitable PackageKit back ends for a multitude of programs such as DNF and Zypper, even for Apt. This guarantees widespread use regardless of choices made about a package system. (See the "Availability" box for more information.)

Availability

Thanks to the relationship to PackageKit, Muon 5 is also harmonized with more than just Kubuntu distributions. Currently, there are packages for Fedora, Debian "Sid", Arch Linux, Open Mandriva Cooker, Rosa and Kubuntu itself. For Kubuntu, the version numbers for the last two LTS distributions are still *2.2.0 and 1.3.1 respectively. If you want to compile Muon by yourself or build a package for other distributions, then you will need numerous dependencies. The basic dependencies include Plasma 5, the Qt bindings for PackageKit, Appstream, Python and also Cmake. Generally speaking, you will need developer files to the extent that your distributions stuffs them in separate sub packages. You can download the current tarball online [4].

Surprisingly, nothing much but the name has stayed the same. Figure 1 shows the start window for Muon, which is invoked via the menu option All applications | System | Program Administration or in the terminal via muon-discover . There are no longer packages per se or references. Instead, you see a tiled view of various software groups. When you click through the first backsplash, you always get to a new one. It soon becomes clear that there are only graphical programs here like Plasma Applets and font packages.

Figure 1: The developers have ceded a lot of space to the KDE logo. Evaluations and other information first appears when you scroll through the contents.

A search for libraries and dev packages leads nowhere. The use of Muon outside of the KDE desktop does not work because Muon does not show Gnome Shell extensions, or theme packages, and other similar items. This needn't be a disadvantage. Users familiar with a smartphone will appreciate how this operates.

Getting to one of the app groups from the start screen requires a double-click. You can open the group with a double-click and see whether it actually contains any apps. If so, then double-click again to open the app you have chosen. Figure 2 shows the page for the translation software Poedit. The information here leaves something to be desired. Aside from one link to the website and a five-star evaluation system, there is not much worth looking at.

Figure 2: The homepage for Poedit in Muon.

The evaluation system does not indicate where the data for the evaluation has come from. Muon does not currently permit evaluations for apps during use. There is also nothing in the web-based app collection from Fedora. Additionally, it is somewhat disconcerting to see after looking through one area that all of the apps have a four-star rating. The user is justified in thinking that the rating is actually just a filler with no basis in fact.

Point: No More Directory Trees

The only reason that the Linux community will not suffer a further divide is because developers are working hard to simplify access to package management. We have been complaining for an eternity that Linux receives too little support from the hardware and software industries.

These complaints are usually answered with the platitude, "We would like to support Linux because this is too expensive due to the small size of the user community." Here we have a classic chicken and egg problem. If Linux stays complex, then users will stay away and the platform will become uninteresting.

Discover represents one of the three components of the Muon package management. KDE distributions such as Netrunner only offer Discover and the Updater after basic installation. However if you are so inclined, you can use Muon to install the central components and quickly make use of the desired QT alternative to Synaptic (Figure 4). Many experienced Linux users put together their own systems anyway no matter what the distributor does. However, beginners find it helpful not to receive hundreds of hits when searching in the package manager for LibreOffice.

Modern package manager front ends, such as Muon Gnome Software and the Ubuntu Software Center, have so far been based only on PackageKit and therefore on Apt, Df, Zypper, Pacman, and friends. There is no reason for lamentations. Still even Linux is influenced by the increasing applification of the IT world. This is especially the case for Ubuntu for which Canonical has been trying for years to establish an actual app store. So far, reception has been lukewarm. Now Snappy [6] and its desktop equivalent Click [7] are supposed to do the trick. The new package manager is completely decoupled from the DEB format and instead places applications together with libraries in "confinements," which are also known as "jails." In theory, this is a good idea for closed source applications. The application only has access to its own data. However, even Google with all of its limitless resources cannot get this right. Just one example of this would be Stagefright [8].

The 2013 declaration concerning the applification of the society [9] makes concrete demands upon manufacturers of operating systems. This is surprising due to the fact these documents are often not very demanding. In the declaration, the officers argue that the manufacturers have a special duty to the users since they offer platforms and therefore create and maintain the framework for using apps. The capital flow from Mark Shuttleworth into Canonical will dwindle away one day. It is not clear whether Ubuntu will have a solid basis for proprietary applications by then and an operable app shop This may indeed come to pass, however the open source community does not take advantage of such efforts. (Christoph Langner)

A Unique Dynamic

Another thing we noticed during the first test was that the software definitely has a life of its own. After installation, Muon quickly searched through software sources for updates and provided prompt reports of the results in the control bar of the KDE desktop. This is fine; information never hurts. However, when Muon Discover starts up – a program that is not actually intended as an update tool – the system secretly downloads the packages from the updates report in the background and then immediately installs them. This is both interesting and irritating at the same time. There is no possibility for the user to manually change this option. The menu option settings , which would be the logical place to look for such a capability, is grayed out and not clickable.

Muon unashamedly helps itself to Debian functionality when it comes to representing screenshots. As a result, the Debian swirl could often be seen in the background even in the test system with Fedora 22. This could be done better, especially because Fedora requires that AppStream [5] files be integrated into packages for delivering data to Muon and other comparable applications. Even if only a few of the graphical application packages that are equipped with a file name appdata.xml came from here and just a few of these contained a link to a screenshot.

System updates are easy to trigger in Muon Discover. You will see an icon sitting next to the magic wand symbol in the toolbar. When clicked, this icon switches the system into update mode. The update tool is also found separately in the KDE menu under Applications | System | Update administration . When started, this tool searches through the package sources for new versions (Figure 3). The activity is a little odd for an app administrator but also beneficial. Updates for graphics programs appear and Muon cannot avoid working at the package layer (Figure 4). Conceptually speaking, Muon wants to make everything disappear. This would be confusing to the smartphone user. In spite of these conceptual leanings, libraries, command-line tools, and script language modules do appear.

Figure 3: A paradigm switch: Packages instead of apps when the system gets updated.
Figure 4: The Muon package manager contains an application that is practically identical to Synaptic in the form of the Package Manager. All packages can be used with this application.

Conclusion

The question of Muon's identity depends on the user. The user who can't or won't become accustomed to graphical package managers or command lines may consider Muon to be the long overdue KDE equivalent to Gnome software. Although there is much to be done on the development front, the current state is a good indicator of what lies ahead. However, Muon 5 lags behind considerably when compared to Gnome software, which has several years on Muon in terms of maturity. If the to-do list found on the tarball is to be believed, then Muon should become an actual software center at some point. It is not clear how this will look.

In particular, users of Muon 2 tend to think of the current versions of the program as a step backward. Even if it is assumed that the broad functionality will become comparable to other products, it is still true that once you get used to command-line tools like Apt, DNF, Pacman, and Zypper, you will find them better suited for managing all packages and not just a subset.

When in doubt, package management also works without an app store clone. Apper offers similar functionality by means of a variety of filters, although this program may never succeed in scaling the heights of integration provided by AppStream. For those who don't want to limit themselves to QT, there is always GTK, which has a number of alternatives.

Counterpoint: Is Everything Merely an App Store?

Since the time of the first open source operating systems, tools like Dpkg and RPM have been bringing order to the systems. The proprietary competitors from Apple and Microsoft offered nothing comparable. As a result, the big advantage to having a Linux system was for a long time the fine-grained and easy-to-use structure of its software manager. Back then, the PC was the usual entry point for initiation into the world of computers. Mobile telephones of the time could be very useful especially when used together with a PDA or a notebook. However, the phones were mostly used just as phones.

The victory march of the feature phone changed all of this. The younger generation no longer makes its first experiences with programmable computing devices at home on a PC. Rather, they may relatively early in life experiment with a smartphone, which can be used for placing calls and also for computing tasks. Although Linux is running in three out of every four of these devices, not much attention has been paid to the advantages of a central package manager. Instead, mobile devices typically have a rigid basic system and a package manager that comes from the manufacturer of the device. These systems are usually difficult to maintain. As a result, software pools have come into existence to make individual apps available for installation.

This is where modern package management tools such as Muon or Gnome are positioned. They are intended to guide users to see exactly what they are accustomed to with mobile devices. This train has already left the station for many developers. But, there are still some users who want the same results as the developers. It is not clear whether the developers will win out.

Undoubtably, this situation will divide users into first class and second class: Those who insist on finding the functionality of their smartphone on their desktop or laptop versus those who are knowledgeable enough that they want to maintain complete control over their own systems. The Linux community is already splintered into factions because of countless incompatible distributions. This issue of who has control will divide the community even further. (Mario Blättermann)

Infos

  1. Synaptic: http://www.nongnu.org/synaptic/
  2. Apt-rpm: http://apt-rpm.org/
  3. PackageKit: http://www.freedesktop.org/software/PackageKit/
  4. Muon tarball: http://download.kde.org/stable/plasma/5.3.2/muon-5.3.2.tar.xz
  5. AppStream: http://www.wikipedia.org/wiki/appstream
  6. Ubuntu Snappy: https://developer.ubuntu.com/en/snappy
  7. Ubuntu Click: https://developer.ubuntu.com/en/publish/packaging-click-apps/
  8. Stagefright exploit in Android: http://www.androidcentral.com/stagefright
  9. Warsaw Declaration on the "Applification" of Society: https://www.priv.gc.ca/information/conf2013/declaration_e.asp

© 2024 Linux New Media USA, LLC – Legal Notice