

Effing Package Management - dominis
https://github.com/jordansissel/fpm/wiki

======
ajross
Yet another attempt to abstract things that cannot be abstracted. Works as
long as your "package" is a blob of files. Doesn't seem to understand anything
else. Some package management systems allow dependencies (on other packages,
on files, or on abstracted "capabilities") that are inherently system-
dependent.

All this provides vs. using plain tarballs (or even "make install") is the
ability to back out and upgrade your custom packages using your system's
package management command.

~~~
imbriaco
It turns out, that's exactly what I want in the world of a configuration
management system like Puppet or Chef.

I don't want my package to try to be clever and configure itself or make lots
of assumptions about how I intend to use it. I'll manage that myself through
other means.

~~~
serverascode
Some standardization in terms of configuration is OK, but you're totally right
that you don't want a bunch of "clever" configuration done by a RPM or OS
level package. I haven't come across many "clever" RPMs in my time though. :)
Mostly I think OS packagers are doing a good job.

------
joeyh
I suppose it's nice that <http://kitenet.net/~joey/code/alien/> finally has
some competition. ;)

I'm unsure of the wisdom of conflating package format conversion (rpm, deb,
puppet) with package building (from gem or python sources).

------
serverascode
I think this is effing awesome, and will be trying it out soon.

Don't understand why devs use apt-get/yum to run their linux desktop but often
code their app in such a way that it can't be managed with OS level packaging.
Don't imagine a lot of developers manage their own personal linux distro.
Probably some... :)

~~~
DanielRibeiro
apt-get has some very disturbing properties, such as the default being system
install.

Bundler (an extension of rubygems) and Maven (for Java) and SBT (for Scala)
have the nice property that different applications can have different versions
of the same libs. And this is the default behavior.

Actually Java, through OSGI, goes out of its way, into allowing different
parts of the _same_ application to require different versions of the same
libs.

Developing software is more complicated than using it. Therefore it needs more
specialized tools.

~~~
serverascode
As far as I can tell, maven was invented for java devs to be able to download
any jar from any where without any concern for where it actually came from or
any requirements for it to be a replicable process.

~~~
DanielRibeiro
More importantly, the project descriptions, like bundler's Gemfile, is a local
decryption of the dependencies. And this allows you to have project scope
libs, instead of system scope libs.

------
draegtun
Also see Acmeist _Package_ which allows you to create packages in CPAN, PyPI
and Ruby Gems.

ref: <https://metacpan.org/module/Package> & <http://acmeism.org/projects/>

------
serverascode
Just used this today to create rpms from the rubygems-mirror and it's
dependencies so that I could install on a redhat server and mirror
rubygems.org for local builds.

Worked great.

------
binarycrusader
The 'solaris' option is a bit bogus though; it should be named 'SVR4'. As of
Solaris 11, SVR4 packages are no longer the expected package format.

