Hacker News Reader

Comment by elsonrodriguez | Hacker News Reader

Find a sysadmin and point them at FPM: https://github.com/jordansissel/fpm

I'd not seen that project; definitely something I'll be looking at, thanks. Unfortunately, for what we're doing, it doesn't look like this will work as is... certainly worth some investigation though.

Good lord. I'll never understand why people promote this project, since it's main feature is that he's doing it wrong. The complexity he's trying to avoid exists for a reason, not because people like complexity.

OP: post here: https://lists.debian.org/debian-jobs/

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.

A thousand times this. As someone who has been fascinated with package management for a long time, my first reaction to FPM was horror. FPM is by and for people who resent package management and want to avoid actual packaging work, not people who are passionate about doing it well.

You want people who, when tasked with creating a package for a distribution format that is new to them, look not to tools like this, but to the conventions and standards of successful distros which use that format as examples.

You want 'native' engagement with those packaging formats, not hacks like FPM. The parent commenter's suggestion is an excellent one.

Please heed this - FPM is basically versioned tarballs. It's only useful for the most simple/contrived scenarios

Actual package specs require effort for good reason. It's not just an archive... but interdependence, steps to perform on (un)installation, changelogs, and so on.

There are some helpers already provided, ie: RPM macros.

Sure, they're esoteric, but show me a specialization that isn't. Refer to the Fedora packaging guidelines and enjoy life.

I love me some fpm, but I recently discovered it has a golang pseudo-replacement: https://github.com/goreleaser/nfpm#readme

It's for sure a ton harder to use (IMHO) because it mandates the creation of a manifest yaml, versus "fpm -s dir -t deb my-directory && echo tada" but not having to deal with ruby (or docker) can make it a better fit for several circumstances

Reply on news.ycombinator.com