[pkg-go] Bug#894131: Bug#894131: prometheus-alertmanager: New upstream release 0.14.0 available. Please package and backport to stretch.

[Martín Ferrari]

Daniel,

On 27/03/18 09:06, Daniel Swarbrick wrote:

> Debian currently has Haskell Platform 2014.2.0.0 (GHC 7.8.3), so to
> build the version of Elm used by Alertmanager, Debian would most likely
> first have to update their Haskell. And so it continues...

Ah, nice..

> I think you idea of stripping away the UI and replacing it with
> something non-standard is not a good idea, because Debian will become
> known as "that distro" which has non-standard Prometheus packages.
> People will either use a different distro, or run it in Docker, or
> something else - in any case, your work will have been for nothing.

Well, I don't really care about being not standard in that sense. The
standard is to run docker packages downloaded from untrusted sources,
fwiw. My objective is to provide sysadmins that align with the Debian
worldview with a working Prometheus stack. I have had already to deviate
from the standard in a few things, for example: kubernetes support was
removed from the prometheus Debian package because it is unmaintainable,
until the k8s people get their act together.

> What exactly in Debian policy is preventing us shipping Alertmanager
> built as intended by upstream?

I don't remember which section in the Policy that is. But those
generated files are not source code, and therefore there is a
requirement to (re)build them from source. It is the same as i was
shipping a pre-compiled .so file.

> Would it be an option to _decompress_ the gzipped & hex-encoded blobs
> from Alertmanager's ui/bindata.go back to their sources and package
> those? Looking at the file, that would produce these files:

This is not really a problem, I am not shipping the binary blob (because
I want to reuse libraries already present in debian). The problem is the
generated code, which is not source code (preferred form of modification).

-- 
Martín Ferrari (Tincho)