chore: contrib: better packaging support

[k0ste]

Import our internal CI spec for build ipmi_exporter. Currently depend on internet

[k0ste]

Fixes #264

[k0ste]

@bitfehler is there any interest to merge this?

[bitfehler]

Not sure, to be honest. This all looks a bit messy, and I am somewhat getting the impression that all this packaging stuff should be removed entirely from the repo.

If I understand correctly, the .spec file is using only files from the Arch Linux (!?) package? So why bother adding the systemd and sudoers file in here?

Doesn't the RPM ecosystem have something like the AUR or whatnot where package definitions can be added with a low barrier to entry? Maybe this EPEL thing or such? (I have never used a RPM-based distro in my life, so no idea what it really is)

[k0ste]

As I said before:

I will try to adjust this SPEC & Archlinux variant to use files from ipmi_exporter tarball

So the steps is:

• Merge this PR
• Produce ipmi_exporter tarball
• Adjust SPEC file for new one tarball
• Merge another PR

Then I go to the Archlinux and make MR that will use shipped with tarball systemd files

[bitfehler]

Ok, then it would make a bit more sense at least, but:

Then I go to the Archlinux and make MR that will use shipped with tarball systemd files

Will they even do that? Is there an example package that uses upstream-supplied systemd files? I find those are pretty heavy with distribution-specific concerns, and I would suspect they would like to exert a certain amount of control over those? I might be wrong, but that would be my gut feeling...

[k0ste]

Ok, then it would make a bit more sense at least, but:

Then I go to the Archlinux and make MR that will use shipped with tarball systemd files

Will they even do that? Is there an example package that uses upstream-supplied systemd files? I find those are pretty heavy with distribution-specific concerns, and I would suspect they would like to exert a certain amount of control over those? I might be wrong, but that would be my gut feeling...

The main issue, is that upstreams provided bad systemd files or not provided files at all. Okay, let's try to answer in another way - what exactly I do for Promethes community:

Better work with DNS for alertmanager#2 & prometheus#1
Better security and network settings for ssl_exporter#1 & the same for ipmi_exporter#1

As you can see, it is not so difficult to make high-quality sytemd service files that will work without the distro specific, if there is an opportunity to test them on production. And it is damn difficult to communicate with each project separately, in at least 50% of cases the contributor does not receive any response at all

And answering your question directly - yes, in Arch it is aimed at using files from the project. A specific example oauth2-proxy/oauth2-proxy#2655 lately package maintainer use this fixes in PKGBUILD

[k0ste]

Last up

[bitfehler]

I inquired with the team, and the official stance is that the source of truth for "how to run stuff" should be [prometheus-community][https://github.com/prometheus-community/ansible]. Patches to the templates in there (see e.g. roles/ipmi_exporter/templates) are always welcome, and distributors are invited to base their unit files on those. The team is occasionally investigating methods to provide packaging, but until a generic solution is found that works for (more or less) all components, the individual exporters should leave packaging to distributors. @SuperQ can confirm that this is team consensus, and I find it the most sensible approach as well.

As such, I am closing this and will also remove the existing packaging stuff in contrib/, it's mostly been broken anyways (for all I can tell, I obviously never used it).

[k0ste]

Thanks for your position, that makes more sense! I'll bring my snippets to Arch.

Also, #264 should be closed