> Agreed, them providing .debs is far from "packaging being a mess". I'm quite happy that they provided .debs, worked with them to make some changes to the debs via pull-requests, and after that have been super happy with the packaging.
Clearly you haven't checked how they build their DEBs and RPMs. Some opaque,
overcomplicated script that eventually calls fpm instead of proper
debianization or spec file for RPM. This results, among the others, in some
configs not being marked as configs.
> I grab and import their packages into my own private repo for historic reasons, but it does mean I have to chase upstream changes. Personally, I think this is a straw-man argument.
It's not. You can't rebuild a server if you suddenly don't have access to
packages this server has installed, especially if you need them to be in
specific versions. BTDT, several times.
First, you need to predict that you'll need to backup software. Typically
people back up their data, as software can be reinstalled (until it can't,
because package retention policies). Then you need to ensure you either have
enough backup space or don't store 30 copies of the same thing, one for each
server (it quite often happens that OS and software weigh much more than data
they host).
Second, restoring from backup limits how you can rebuild a server to just one
rigid way. You can't bring another already running server to what you have
elsewhere.
Sorry, I assumed you were talking about rebuilding a local mirror repository that you use to provide software for your other hosts. That would just be one backup of the packages and meta data that you can restore. Is there a reason you can't mirror the packages and repositories you use?
Just mirroring doesn't change the retention policy (unless the term has
changed its meaning in recent fifteen years), so it won't do. But this is
moves the discussion to spoken language semantics, which I don't feel like
pushing too far.
My point with the packages is that you need your own copy that you have
control over, so they don't disappear unexpectedly. Pulling already-built
packages from some other repository would be fine from this standpoint, though
I prefer rebuilding them myself and keeping along with source packages.
Clearly you haven't checked how they build their DEBs and RPMs. Some opaque, overcomplicated script that eventually calls fpm instead of proper debianization or spec file for RPM. This results, among the others, in some configs not being marked as configs.
> I grab and import their packages into my own private repo for historic reasons, but it does mean I have to chase upstream changes. Personally, I think this is a straw-man argument.
It's not. You can't rebuild a server if you suddenly don't have access to packages this server has installed, especially if you need them to be in specific versions. BTDT, several times.