RPM Community Forums

Mailing List Message of <rpm-users>

RE: Info needed - Packages vs compiling on production

From: <pinto.elia@gmail.com>
Date: Mon 21 Feb 2011 - 21:35:48 CET
Message-ID: <4d62cca9.460ae30a.21c4.22d6@mx.google.com>
It is the same my reasoning for loving to use a (good) package management system. Also in these days i have to discuss with luser Why is a good thing to have also a commercial application packaged with rpm, instead to use something a gold image, that not permit to upgrade a software without a manual and costly process. And the luser like don't remember that they  have to backup all the system, instead of only the application data, at every upgrade. But with a process often not repetable or verificable. Using a package management system as rpm and a centralized configuration engine as puppet permit to reduce drasticaly the cost to mantain a complex it infrastrutture, permit to render it verificable, diminuish the cost to setup and mantain it operational. And think how  to do patch management, compliance etc without such solid foundation. the manual process is a no op in these case. The gold image approch help only only in first install but no after. This  look simple enough to understeand but it is often negleted. Just an another opinion. I Hope not so OT .  Regards 
-----Original Message-----
From: Jeff Johnson
Sent:  21/02/2011, 19:45 
To: rpm-users@rpm5.org
Subject: Re: Info needed - Packages vs compiling on production



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

(aside)
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
> (http://en.wikipedia.org/wiki/Package_management_system)
> - 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".
pleases noone.


> 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
	make world
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".

Caveat:
	My opinions aren't typical of most RPM users.

73 de jeff
Received on Mon Feb 21 21:35:57 2011
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.