It depends on what you want as a result. Do you want the shortest path to "dpkg -i the-result.deb" working on your server, or do you want a package complying with debian standards around behaviour and file locations, with packaging/source changelog split, potentially upstreamable? Because the second one is a lot more work, but few people actually need that.
The second one is more work and it's what you want. Because it gets stuff into the main archive that everybody benefits from in the future. Otherwise your project is a series of hacks that create an unmaintainable mess.
No, sometimes you really don't care about that. Some software will always stay internal. Some is so specific that it will never get to a distro. Some is just experimental and providing standards-compliant packaging for it is a waste of time. And that's when FPM can be useful if you want to go that way.
Yeah, FPM is great not for official/public packages (or libraries) but for "for some reason our $org installs internal (or patched, or just self-built OSS) stuff via package manager" and most often even all the versions, like /opt/foo-1.0, /opt/foo-1.1 and so on. It solves this problem very well.
I'd say it solves it passably, in the simplest and most minimalistic way possible to still call them packages, technically.
I question how one gets here, nay, the 'problem' we're solving.
Presumably there's config management involved already capable of shipping bits. ie: the repo definitions to find these hackjob packages, or deliver them directly.
If this is what you're willing to invest, go Slackware at it - use a tarball. You aren't gaining anything notable by throwing an archive at a packaging format.
The meta that FPM ignores is what provides packages their value! If changelogs were at least a part of it, I'd be a bit more accepting.
Otherwise, I see it mainly as misappropriation. Best case, naive and well served. Worst case, giving the impression of better distribution than actually exists
An organization that does packages, but leaves this as the answer, fails itself and the members. Over 90% of the purpose is dutifully ignored/not standardized
It is also a branding problem, imo. Part of the reason I prefer software from distro repositories is because those conventions the distro maintainers enforce help ensure that packages won't do stupid things and break my system.
Especially with DEB and RPM, where the packaging format supports arbitrary hooks that run as root, this is a big deal. High quality packages that meet distro standards will inspire confidence in customers' sysadmins. Substandard packaging may do disservice to your core software's brand, if your actual software is more solid and thoughtful than the packaging.
