Effing Package Management | Hacker News Reader

Effing Package Management

github.com

27 pointsdominis13 comments

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.

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.

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.

Don't forget that if it's a RPM that comes out of the process you can gpg sign it, and verify the files that it provided when your server gets hacked. Sure, yeah, you can do that with a tar file, but it's pretty easy to run one command on a server and see what's changed.

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).

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... :)

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.

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.

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.

It is easy to use apt-get/yum, and necessary for installing lots of vital programs.

On the other hand, I have no idea how I would go about making my apps work with app-get. I'm sure I could go and learn, but I suspect it will be non trivial, and I have an awful feeling it will involve learning automake/autoconf.

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/

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.

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.

Reply on news.ycombinator.com