> Seems everyone has opinions on packaging and you know what it's like when everyone has opinions, right? :)
Don't try to push this into opinion realm, because it's not, it's a standards
realm. Your package doesn't stand lintian test, and it's not
a doesn't-really-matter type of errors that there's no README or license file.
You don't even put an initscript in packages in a proper way.
It wouldn't matter that much, but your build system doesn't have an easy,
clean build from local source tree with a method of putting files in right
places in $DESTDIR, so the software could be properly debianized (or
equivalent) by somebody else.
No. Why would I do so if I don't use your software, given that your product
feels more like a paid thing than open source? You have enough money to hire
competent sysadmin to teach you how to package software.
I'm glad you answered your own question, but it was you who asked that.
I couldn't care less if they provided APT repository; using random
repositories from various companies is asking for trouble with managing your
servers (hint: package retention policies).
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. 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. With many places not even providing packages, I'm glad that the Influx folks went through that process for me.
> 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.
