5 ms·
I'm a bit wary of calling an fpm-generated deb a native package, those are about as well integrated as a checkinstall (make install -> deb) or an alien (rpm ->
by obtu 14y ago
I'm a bit wary of calling an fpm-generated deb a native package, those are about as well integrated as a checkinstall (make install -> deb) or an alien (rpm -> deb) package. fpm may still be useful for this use case, but it doesn't take me much more effort to get a proper source package.
- hynek 14y agoWe used to use native tooling, the usage of fpm is rather new in fact. It simplified the code big time without compromising on anything.
- mattyb 14y agoHow are FPM-generated debs any less integrated than native packages? You have the same control over the package metadata using its flags as you do with a Debian control file, and using `-s dir`, you have complete control over the package contents. You can ship rc/Upstart scripts, use pre/post-inst/rm scripts to add users and backup data, etc. These are all the same tasks that lots of Debian-maintained packages perform. Please look at the FPM wiki, you'll see that it offers many more options for integration than checkinstall (which I used to use, and hated): https://github.com/jordansissel/fpm/wiki https://github.com/jordansissel/fpm/wiki And why would you want to create source packages? One of the benefits to generating binary packages is that you compile once and roll it out to hundreds of servers. I'd rather not have to compile, say, Erlang on every target server.