FPM-created packages suck. They often have incorrect metadata format, most of
the time they don't have any dependencies encoded, they often have crappily
written initscripts (less of a problem today, with systemd everywhere) and
similar infrastructural things.
All that while writing RPM specs and proper(ish) debianization are quite easy.
> (less of a problem today, with systemd everywhere)
Systemd is far from everywhere. Ubuntu 14.04 doesn't use it and is supported until 2019. Debian Wheezy is supported until 2018. RHEL 6 has support through to 2021.
Overall this means it'll start to be reasonable to presume systemd sometime around 2020, and be realistically almost everywhere from say 2025.
Software changes take 5-10 years to roll out everywhere. This is such a core change that it'll be on the longer side.
Even though I agree with you here (I still use Wheezy, personally and
professionally), most projects don't target that old releases, so they build
mainly for modern mainstream (Debian/Ubuntu and Red Hat/CentOS), which means
systemd.
And that still doesn't change the fact that most programmers produce shitty
packages, if any, so every time I use somebody's software I need to package it
myself to have it properly built.
And for each and every package/project I would need convince the maintainer
that he doesn't understand what he's doing, he's doing it wrong, and he should
learn a correct method? Because it all boils to this (barring a more polite
way of stating the fact).
Https://github.com/alanfranz/fpm-within-docker for native packages.