Support building Linux distribution packages

[SuperQ]

It would be useful to add a packages command that would build deb and rpm format packages for various Linux distributions.

We could use native packaging utilties, or something fpm.

[brian-brazil]

I'm wary of this. Building a package that works on your own systems is easy. Building packages that work on the myriad of variants of distros out there and the support that comes from that variation is not.

[pete-leese]

I think it would certainly be an advantage for the project to release packages for a number of reasons and any fears can easily be alleviated.

• Makes Prometheus more accessible to the masses (easier to install and update)
• installation / setup Consistency

Ubuntu & Debian
Standalone Linux Binaries
Redhat & Centos

I don't think support should be any greater than that to be honest and would limit to .deb .rpm - once the first generic package has been created then subsequent upgrade will fall in-line so there will be little in terms of variance.

I am certainly more than happy to help test and feedback, but this is defiantly a good thing.

Thanks.

Pete

[brian-brazil]

@VR6Pete I don't think you appreciate the nature of the variation. At the simplest, what if some distros are using SysV init, others systmed and some upstart? Different distros put things in different places with different policies, and that's before you even get to per-site variations.

If you want Debian packages for example, Debian already have those and they follow their policies.

[pete-leese]

I have been packaging software for over 10 years so know exactly the type of challenges you can face, but simply cannot dismiss it on that basis, and you have to start somewhere so to speak and many other vendors have dealt with this type of issue and have released working binaries.

A good starting point would be to look at how Grafana have done - I don't think the wheel needs to be re-invented here.

https://grafana.com/grafana/download/

[brian-brazil]

It's not a matter of releasing working binaries, it's about working packages.

I would not consider Grafana an example of good packaging, as they still have to get service management right.

[SuperQ]

@brian-brazil The Debian package builder, for example, automatically handles various init systems, this is pretty easy to deal with these days.

[SuperQ]

The problem with Debian is they don't follow our vendoring, or our release cycle very closely. I would much prefer to provide our own packages, so users can follow our release cycle more easily.

[pete-leese]

Many other projects generate nightly builds in a number of package formats successfully, I wouldn’t be too concerned.

[fredbcode]

Yes very useful, I'm using the latest grafana version with an old Prometheus
Continuous Integration to be facilitated (very) by packages

[SuperQ]

This might be easier to integrate: https://github.com/goreleaser/nfpm#usage-as-lib

[roidelapluie]

I am willing to work on this.

[mario-pranjic]

Count me in for debian related packaging.

[bitfehler]

Just my two cents: this seem ill-advised to me. Such code would be best kept in distributions, as they are the ones who make the ultimate decisions about how to package things. For example, many distros have their own re-usable code for e.g. "a rust app", or "an npm module" or such. So the best that could be done is to provide a uniform way to build exporters (essentially done, but of course ongoing), so that distributions can build such a re-usable module for exporters. But there might always be exceptions, and they should ultimately be handled at distribution level.

[SuperQ]

The problem is distributions definitely can't keep up with the pace of of our development. Also they make questionable choices like re-packaging all dependencies, ignoring the go.mod files. This has caused several bugs, for example Debian included an incorrect procfs package version for the node_exporter. This caused a couple of bugs that were fixed to be released into stable.

[bitfehler]

I don't see how any of that would change by providing a way to build packages. The distributions that make questionable choices will still make those and not package what you provide. If you just provide packages for download, people will stick to old versions (because their package manager doesn't update them) - another cause for unnecessary bug reports. If you really intend to run a package repository, I would tip my hat, but that is a pretty substantial amount of work.

Also, what exactly would be the scope here? Which distributions? Which derivatives? Which versions? etc...

[SuperQ]

We planned to combine our packages with distribution publishing via something like packagecloud.

[jsirianni]

I think Linux package support would be a great addition, even if it means they are served from the releases page. Installing Prometheus onto a systemd based server by hand is not fun.

I was able to implement a solution today for a personal project. Using Goreleaser, but I am sure Promu can be extended to support building linux packages with the nFPM package that Goreleaser uses.

My example is a basic distribution agnostic solution with inspec (cinc) tests for install and uninstall.

If anyone is interested, ill leave this PR open.

[SuperQ]

Thanks. I think the main issue is that your implementation adds a lot of boiler plate. We have something like 50 exporter repos that are downstream from promu. Not to mention any non-official exporters that use our build system.

We want to be able to produce packages with the minimum amount of downstream work possible.

[conallob]

Is this effort still ongoing? If not, could i help?

For reference, https://github.com/Shopify/toxiproxy shows a goreleaser github config doesn't need to include a huge amount of boilerplate.