Distribution packaging of software needs to be informed (and useful)

May 28, 2019

In my recent entry on a RPM name clash between grafana.com's and Fedora's packaging of Grafana, Josef "Jeff" Sipek wrote in a comment:

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 fundamentally disagree with this view as it plays out in the case of the 'grafana' RPM package name (where grafana.com packaged it long before Fedora did). At the immediate level, when the upstream already distributes a package for the thing (either as a standalone package, the case here, or through an addon repository), it is up to the distribution, as the second person on the scene, to make sure that they work with the existing situation unless it is completely untenable to do so.

(On a purely practical level, saying 'the distribution can take over your existing package name any time it feels like and cause arbitrary problems for current users' is a great way to get upstreams to never make their own packages for a distribution and to only every release tarballs. I feel strongly that this would be a loss; tarballs are strongly inferior to proper packages for various reasons.)

More broadly, when a distribution creates a package for something, they absolutely should inform themselves about how the thing is currently packaged, distributed, installed, and used on their distribution, if it is, and how it will be used and evolve in the future. Fundamentally, a distribution should be creating useful packages of programs and being informed is part of that. Blindly grabbing a release of something and packaging it as an official distribution package is not necessarily creating a useful thing for anyone, either current users or potential future users who might install the distribution's package. Doing a good, useful package fundamentally requires understanding things like how the upstream distributes things, what their release schedule is like, how they support old releases (if they do), and so on. It cannot be done blindly, even in cases where the upstream is not already providing its own packages.

(For example, if you package and freeze a version of something that will have that version abandoned immediately by the upstream and not have fixes, security updates and so on backported by you, you are not creating a useful package; instead, you're creating a dangerous one. In some cases this means that you cannot create a distribution package that is both in compliance with distribution packaging policies and useful to your users; in that case, you should not package it at all. If users keep asking, set up a web page for 'why we cannot provide a package for this'.)

PS: Some of this is moot if the upstream does not distribute their own pre-built binaries, but even then you really want to know the upstream's release schedule, length of version support, degree of version to version change, and so on. If the upstream believes in routine significant change, no support of old versions, and frequent releases, you probably do not want to touch that minefield. In the modern world, it is an unfortunate fact of life that not every upstream project is suitable for being packaged by distributions, even if this leaves your users to deal with the problem themselves. It's better to be honest about the upstream project being incompatible with what your users expect from your packages.

Comments on this page:

By Slavko at 2019-05-29 13:25:14:

I am not using Fedora, but Debian for years, i was maintainer of some of its official packages (until some healthy problems happens) and i still maintain own APT repository, with some tweaked official and other missing packages.

I think, that this situation with Fedora & Grafana is unfair example and it tends into wrong results about distribution packaging. AFAIK, the distributions are named "distributions" because they distributes (a lot of) software, not because they distributes Linux (as OS). By first, your post is unfair, because lack of one package (maintainer) activity in ine distribution has nothing to do with other packages nor with other distributions. Second, naming distribution package by the upstream project name is good practice, because one can simple find package for it. Third, using third party packages is on user's responsibility.

I use more packages from third party sources (including my own). If i don't want to they are replaced by official update, i can/have to use packaging tools to prevent this happens in future, or simple take care about this and do not blame the distribution. A lot of upstream cooperates with package maintainers (some are maintainers itself), but there is lack of effort from Grafana side (at least with Debian).

I played with Grafana in Debian some time ago (i abandon grafana for unrelated reasons, which i will not mention here) and i used the upstream packages, because here is not distribution's package and building own is not trivial due it's dependencies. I found the upstream package as unprofessional, the upgrade fails, the service itself is not stopped on package uninstall, etc. There are not source packages, to one can review compile process and/or rebuild package by own.

The biggest one no-no (for me) is home call enabled by default and done automatically on first start attempt without asking. Then i consider, that while grafana is OSS software, packages provided by them are intentionally simple commercial ads. Then, if you want blame someone, try to start looking on self or grafana side...

By Carsten at 2019-05-29 15:50:17:

This reminds me of a talk about why linux has not taken over the desktop yet. The argument was made that windows offered a platform (you simply offer installer.exe on your website), while on linux you had to "get into" the many distributions. I do not know how important this difference is in practice, but I found it interesting.

Written on 28 May 2019.
« An interesting report on newly used domain names and their usage in spam
Conditional expressions in any form are an attractive thing »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue May 28 23:57:21 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.