On Feb 21, 2011, at 1:16 PM, Sriram Narayanan wrote:
> Hi everyone:
> I'm asking this question here since there are many distribution
> builders on this list.
> I'm having a discussion with some colleagues about the merits of
> installing native libraries via a package manager than by compiling
> source on production.
> Compiling source on production is how most Ruby application developers
> deploy rubygems having native bindings onto production servers.
SHort answer: both get the job done.
Package management scales, rebiuilding does not.
And package management tracks software over its entire life-cycle,
its not just "installing".
In fact, the poorly understood reason for RPM's success -- everyone
is so so busy chanting "dependency hell" instead -- is that rpm
has flawless erases, cleans up everything, never misses.
> My reasoning for using package managers includes the following:
> - the various benefits listed at wikipedia
> - dependency resolution
> - file verification (e.g. rpm -V)
> - roll forward - roll back - to the extent possible by various package managers
Well --rollback is (mostly) not part of package management. There are only
a few package managers (nix and conary come to mind) that can really do
--rollback without caveats like "... to the extent possible ...".
The killer for --rollback in package management is the instantaneous
(and quite predictable) RFE from users:
How do I rollback everything except blah?
and the short answer
You don't, that's not how --rollback "works".
> My reasoning against compiling on production:
> - doesn't help resolve dependency hell when you start to upgrade
> libraries partly (when A depends on J1 and B1, while B1 depends on
> J2). A package manager would tell you very quickly when you run into
> such situations.
> - There's some message somewhere about installing only the bare
> minimum files onto a production server. Compilers and Devel files are
> not required on production.
> Have such topics been discussed somewhere ? Have you faced such
> questions from your end users or in life ?
The archetype for your question goes way way way back to *BSD
as opposed to binary package management (there are source (my words) package managers
like MacPorts too).
The best answer I (I'm an old school *BSD developer) know of to
"make world" <-> rpm
I got from Erik Troan a long time ago and illustrates the "support" scaling
that comes from doing binary package management:
Let's say you build & test a package and it "works".
Now put that package on a DVD, wait a year or two.
Go find the DVD, install the package, and horrors! the package DOES NOT WORK.
The trick question is this
Q: Where do you look to fix the problem?
A: Not the binary package: it was "known good" and verifiably hasn't changed.
Its the long shelf life, and minimizing "support" necessary for "make world" distros
that scales and makes RPM worth the pain of wrestling with "dependency hell".
My opinions aren't typical of most RPM users.
73 de jeff
Received on Mon Feb 21 19:46:09 2011
- application/pkcs7-signature attachment: smime.p7s