Chris's Wiki :: blog/linux/PackageNameClashProblem

Something that Linux distributions should not do when packaging things

May 27, 2019

Right now I am a bit unhappy at Fedora for a specific packaging situation, so let me tell you a little story of what I, as a system administrator, would really like distributions to not do.

For reasons beyond the scope of this blog entry, I run a Prometheus and Grafana setup on both my home and office Fedora Linux machines (among other things, it gives me a place to test out various things involving them). When I set this up, I used the official upstream versions of both, because I needed to match what we are running (or would soon be). The Grafana people supply Grafana in a variety of package formats, and because Grafana has a bunch of files and paths I opted to use their RPM package instead of their tarball. The Grafana people give their RPM package the package name of 'grafana', which is perfectly reasonable of them.

(We use the .deb on our Ubuntu 18.04 based production server for the same reason. Life is too short to spend patiently setting tons of command line switches or configuration file paths to tell something where to find all of its bits if the people provide a nice pre-packaged artifact.)

Recently, Fedora decided to package Grafana themselves (as a RPM), and they called this RPM package 'grafana'. Since the two different packages are different versions of the same thing as far as package management tools are concerned, Fedora basically took over the 'grafana' package name from Grafana. This caused my systems to offer to upgrade me from the Grafana.com 'grafana-6.1.5-1' package to the Fedora 'grafana-6.1.6-1.fc29' one, which I actually did after taking reasonable steps to make sure that the Fedora version of 6.1.6 was compatible with the file layouts and so on from the Grafana version of 6.1.5.

So far, I have no objection to what Fedora did. They provided the latest released version of Grafana, and their new package was a drop in replacement for the upstream Grafana RPM. The problem is what happened next, which is that the Grafana people released Grafana 6.2 on May 22nd (cf) and currently there is no sign of any update to the Fedora package (the Bodhi page for grafana has no activity since 6.1.6, for example). At this point it is unclear to me if Fedora has any plans to update from 6.1.6 at all, for example; perhaps they have decided to freeze on this initial version.

Why is this a problem? It's simple. If you're going to take over a package name from the upstream, you should keep up with the upstream releases. If you take over a package name and don't keep up to date or keep up to date only sporadically, you cause all sorts of heartburn for system administrators who use the package. The least annoying future of this situation is that Fedora has abandoned Grafana at 6.1.6 and I am going to 'upgrade' it with the upstream 6.2.1, which will hopefully be a transparent replacement and not blow up in my face. The most annoying future is that Fedora and Grafana keep ping-ponging versions back and forth, which will make 'dnf upgrade' into a minefield (because it will frequently try to give me a 'grafana' upgrade that I don't want and that would be dangerous to accept). And of course this situation turns Fedora version upgrades into their own minefield, since now I risk an upgrade to Fedora 30 actually reverting the 'grafana' package version on me.

You can hardly miss that Grafana.com already supplies a 'grafana' RPM; it's right there on their download page. In this situation I feel that the correct thing for a Linux distribution to do is to pick another package name, one that doesn't clash with the upstream's established packaging. If you can't stand doing this, don't package the software at all.

(Fedora's packaging of Prometheus itself is fairly amusing in a terrible way, since they only provide the extremely obsolete 1.8.0 release (which is no longer supported upstream or really by anyone). Prometheus 2.x is a major improvement that everyone should be using, and 2.0.0 was released way back in November of 2017, more than a year and a half ago. At this point, Fedora should just remove their Prometheus packages from the next version of Fedora.)

Comments on this page:

From 157.52.27.216 at 2019-05-27 22:37:17:

For the record, if anyone is looking for a workaround for this problem, in the Debian/Ubuntu world you can use apt_preferences(5) to "pin" certain packages to certain releases or repo URLs (search for "origin"):

https://wiki.debian.org/AptPreferences

https://manpages.debian.org/stretch/apt/apt_preferences.5.en.html

The general point still stands though.

By Albert at 2019-05-28 04:35:14:

Things like these are the reason I run grafana (and other software) in a dedicated docker container (with an external data volume, of course).

https://hub.docker.com/r/grafana/grafana

By Zelial at 2019-05-28 06:11:55:

Devils advocate hete: As a Linux distro user, when searching for a piece of software, I check the distribution packages first. And I hate it when the package name does not match the software name. Discoverability--.

If grafana wants their users to be able to keep the newest version, they should provide a repo file instead of an rpm package.

If you want to use a non-distro content even when fresher, distro - provided content is available, you can (masking, versionlock). But this should not be default behavior.

By Josef "Jeff" Sipek at 2019-05-28 08:52:15:

If you take over a package name...

I think that's a bit backwards. I always consider the distro as the owner of the package namespace. So, it's really up to grafana.com to use a non-colliding name.

The distro provides a self-contained ecosystem, if a 3rd party package wants to work with it, then it should be up to the 3rd party to do all the work. There's no reasonable way for Fedora (or any other distro) to know about every other possible package on the web that may get installed.

I remember hearing that rpm has a "generation" number, so it's totally reasonable for grafana.com to use a higher number than Fedora does, thereby always superseding all Fedora versions. Again, this is up to the 3rd party to fix.

I don't know if there is a way to "hold" a particular package/version in rpm, but there really ought to be.

Out of curiosity, would IPS's sticky publisher concept solve this issue?

Yeah, it sucks to be the sysadmin suck in the middle.

By Ben Cotton at 2019-05-28 09:08:08:

Full disclosure: I am the Fedora Program Manager

I understand the frustration, but I think this is the right behavior for a distro. Otherwise, we end up with a different name for every package from the kernel up — or worse, some packages have distro-specific names and some don't. That's even more confusing for users. Most upstreams don't provide rpms, so it's rarely an issue. For your case, I would suggest using the exclude setting in the Fedora repo config files so that the grafana package comes from the upstream repo instead of Fedora's.

By A dude at 2019-05-28 09:51:20:

You can just disable grafana in the Fedora repo. Check out the "exclude" option in the "Configuring DNF and DNF Repositories" section in the Fedora manual: https://docs.fedoraproject.org/en-US/fedora/f30/system-administrators-guide/package-management/DNF/

By eclipseo at 2019-05-28 10:31:25:

Prometheus will be updated to 2.9.2 for F31 along with the rest of the Golang stack (if we keep our timeline, see https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines). I don't know if we will backport it to F29/F30.

By cks at 2019-05-29 00:15:15:

eclipseo: Prometheus just released version 2.10 and in general is on a six week release cadence of new 2.x versions, so I hope that F31 will not literally be packaging 2.9.2 but instead whatever is current at the time of the freeze. Probably Fedora should then track new versions, since Prometheus does not provide fixes or security updates for older ones. (They don't promise to always be compatible either, but this is a case where you get to pick your poison.)

In general, if Fedora was going to keep promptly up to date with Grafana versions, I would prefer to use the official packages; I trust Fedora's packaging more. But Grafana does not support older versions, only the current one, so if Fedora is going to be (significantly) slow I have no real choice. As far as who owns the package namespace and any particular name, in this case Grafana was providing a 'grafana' RPM long before Fedora packaged it. As far as finding things by their 'obvious' name, this is not something that Fedora necessarily follows; in practice, you always need to use eg 'dnf list *grafana*'.

(Prometheus is universally known as 'prometheus', which is also the binary name, but the Fedora package is 'golang-github-prometheus-prometheus'. If you know Fedora's Go packaging policies, maybe you could predict that, but I can't. And Grafana is a significantly Go based package too, which would theoretically make the Fedora package name be 'golang-github-grafana-grafana' (yes, it has significant non-Go assets, which might be enough to change things, but then the binary is actually 'grafana-server').)

I had forgotten (or never known) that excludes can be configured in the repo conf.d files, so I'm glad to hear or be reminded about that. If I wind up deciding to always use the Grafana upstream package, I will probably have to do that (and I think it should also work during live Fedora upgrades with dnf.)

I also wrote some more about my views of the general issues in PackagingMustBeInformed.

Written on 27 May 2019.

«	Why I no longer have strong feelings about changes to Python

An interesting report on newly used domain names and their usage in spam