It happens to me to discover some quirks and facts by accident. Today, something that made me question the design of zypper, a crucial openSUSE tool! Here’s the full story, which is a very short one.

Linux Lite has a very nice System Monitoring Center, which is a fork of Hakan Dündar’s homonymous tool, which has been abandoned, unfortunately:

*** Announcement (31.10.2023): End of support for System Monitoring Center v2.x.x. The project is ended. System Monitoring Center 12.2020-10.2023. ***

Besides that, the two tools look radically different. Here’s the original one (version 2.26.0):

And here’s Jerry Bezencon’s fork for Linux Lite (version 6.8.1):

Jerry’s is better because it can show all the cores (threads, actually) at once. This is the major flaw of the original tool.

What happens is that I tried to build Jerry’s one, but being a Python thing, I didn’t know what to do. There isn’t anything to configure, and no makefile, just a bunch of files that needed to be packaged into a .deb, which I have no idea how to do. Without a .spec, I cannot build a .rpm, and the sources offered by Jerry are not offered in good faith.

To have been offered in good faith means to have the source package, which in Debian isn’t another .deb (oh, .rpm is so consistent!), but a trio: (1) a .dsc file, (2) the original sources as .tar.xz, and (3) a .debian.tar.xz that includes the actions to be taken to patch the sources and build the installable .deb package. In the absence of the last one, I can’t figure out what to do, other than to copy those files in the filesystem. This could have been enough, but I still wanted either to install a package, or to use make.

Either way, I played with the .deb file for Linux Lite, thinking that, given that it’s only a bunch of .py and images, it should be convertible with alien into a .rpm, which would then be installable. Dependency issues were to be expected due to different package naming in Ubuntu vs RHEL, but I wanted to give it a try.

You won’t guess what errors were thrown by rpm -i! It said that the .rpm file obtained through conversion by alien wanted to override dozens of files that were actually system directories, such as:

  • /usr/bin
  • /usr/lib
  • /usr/share
  • /usr/share/icons/hicolor/scalable
  • /usr/share/locale/pt_BR

and so on. Well, to be more accurate, the errors were phrased like this:

file /usr/share from install of system-monitoring-center_6.8.1.noarch conflicts with file from package filesystem-3.16-2.el9.x86_64

Of course, RPM is stupid:

  1. While everything is a file in Linux, these are folders, and this is an important distinction, especially as it’s not apparent what exactly can conflict with a folder that exists since the OS has been installed, and in which all packages install files!
  2. The nature of the conflict is unspecified. Most people would think in terms of overwriting a file, which is not the case here.

To find what exactly was about to be overridden or overwritten, one should use rpm -V. And then, for all the conflicting “files” (folders), the line would start with this:

.M.......

That means (what, isn’t it self-explanatory?) that what’s different between the two versions is related to the Mode, which includes the permissions and the file type.

Further clarifications come from this openSUSE forum thread, in which someone complained that:

  1. rpm refused to install a rpm, with exactly this type of conflict, but
  2. zypper just went along and installed it, no complaints, no questionx asked.

A nincompoop (see, I can use words other than “retard”!) came with this retarded (ouch!) thing in the context, as he clearly failed to read the exact error message:

zypper does check the whole situation and acts accordingly, it will e.g. install extra packages when they are dependencies, or offer you to choose a solution as in this case.

This is not about rpm vs zypper, because Red Hat too has a dependency solver called dnf (yum in the past).

Thankfully, the last comment is correct and enlightening:

RPM is correct here.

It has nothing to do with dependencies. zypper does equivalent of “rpm --nodeps --force --noscripts” and evaluates dependencies and conflicts itself. In this case, filesystem package has /usr/share with modes 0555 (r-xr-xr-x) while master-pdf package has /usr/share with modes -755 (rwxr-xr-x). So forcing installation makes this directory writable.

RPM allows directories “shared” between packages as long as their attributes are identical. Here attributes are different, so RPM quite correctly refuses to install (without forcing installation). Zypper pretends to know better than RPM but does not implement this check.

That’s 100% right.

I didn’t check the modes in Jerry’s .deb and how alien has ported them to the .rpm, nor were those of the system directories. It’s enough that they’re different. Now, I have two takeaways:

RPM is right in principle, but it’s stupid in practice. It’s right to refuse to alter the permissions of system folders. It’s stupid because:

  1. It doesn’t say explicitly: “folder1 with mode -755 from package1 wants to override mode 0555 from package2”. WTF, is it so difficult to spit out the reason?
  2. It doesn’t include an option to ignore all the conflicts by doing nothing but going on with the non-conflicting actions, i.e. by skipping the respective files or folders! In this case, as well as the case in that forum, the package wanted to create those folders, but as they already exist, it’s enough to copy inside the actual files. It would have been rocket science for rpm to ask: “package1 wants to create or modify existing directories: ignore or abort?” Of course it would be. We’re in 1997.

Zypper is much worse. First, it doesn’t check the modes; it is indeed behaving like “rpm --nodeps --force --noscripts”. Or, if it’s actually silently ignoring the conflicts despite being aware of them, what is it that it’s doing?

  1. It ignores the mode change request, which is what rpm should do, if not by default, then by using a flag.
  2. It honors the mode change request, thus potentially breaking the security of the system.

We cannot know. The only way to find out is to install such a package with zypper, and compare the modes of the conflicting folders before and after the installation. But to know that there are such conflicts, one should first use rpm and fail!

This is completely insane. I just lost my confidence in Zypper and in openSUSE!

Incidentally, the permissions in Linux Lite are correct. I checked the Live ISO, and permissions for /usr/share are drwxr-xr-x (0755) in both Linux Lite 7 and AlmaLinux 9.4. So the queer rpm could be the result of a bad conversion by alien. Or maybe the .deb itself has issues, but Linux Lite comes with the package preinstalled, so nobody noticed unless they uninstalled and reinstalled the package. And I’ll never know how would dpkg and apt behave in the case of such conflicts… because I don’t feel like investigating.

UPDATE: I just checked what Zypper does, and I actually tried YaST Software, the GUI version. I used the .rpm converted from .deb by alien under AlmaLinux, because the unofficial builds of alien available for openSUSE Leap failed to work.

I can confirm that zypper silently accepts overriding the modes (permissions) of system directories without raising any warning, let alone asking the user for confirmation!

Before installing of that package:

After having installed that package:

Now, /usr/bin, /usr/lib and /usr/share have been made writable! OK, they’re now writable by the members of the group (root), not by others, but this is a matter of principle: the standard permissions for system directories are there for a reason, and changing them without even informing the user is unacceptable!

OpenSUSE, you suck. You’re insecure. Why are people still using you?