Package management

Tue May 15 14:02:58 EDT 2007

Expand your environment. Segment your apps onto independent
server/instances to avoid issues like library/application conflicts. ssh
and scp with keys are fine tools to move data around and start
processes. If that means buying more machines or using virtualization so
be it, but it's easier (imho) to deal with 12 server instances with
different os version than 1 server with 12 hacked together services on
it. Shoe horning a bunch of stuff into one host is a fun excercise, but
in the end it is usually a waste of time that breaks or can't be updated
and when the hardware goes so do *ALL* of your servers. *Bonus points*
Virtualization allows you to move resource hogging hosts to their own
hardware at a later date easily. There is a free VMware server (kinda
slow on io) and a bunch of prebuilt os images for running various
applications. The images are compatible with the expensive VMware which
you can buy at 15 hundred bucks a processor but gives you pretty good
performance (still not native speeds). You could also use something like
xen or kvm. Alot of people push for things like paravirtualization for
speed reasons if you do virtualization, but I look for ease of
managability and flexibility which seems to you want as well, and
paravirtualation seems to need to have a pretty homogenous environment. 

Oh and I like it for troubleshooting apps. Boot WinXP sp1 for some
testing, then try WinXP sp2. Boot up the "Dev" mail server try a new
program. On shutdown revert to the clean install. It's pretty nifty
stuff that you can get for free if you can deal with the performance
degredation. If it works well enough you can pay if you want better
performance/support or tar dump the filesystem to a new machine later
on.

However, if you must shoehorn....

Approach it by sticking with a distro without any licensing restrictions
that does rolling releases. Debian comes to mind, but there are most
likely others. The licensing freedom is to remove the monitary issues
with doing chroots (see below) or virtual instances. Rolling distros
will have more granular package releases that will give you greater
flexibility when you cross install. They also tend to be a bit better
naming libraries and apps to avoid conflicts. 

In Debian you can install packages from a backport repository or a newer
release by changing a config file or running apt with some extra
arguments. That *should* install all the dependencies as well. CentOS's
yum has the same feature and there are extra repositories like dag and
CentOSplus that serve situations like this. You can also help yourself
out by making a local mirror and controling what versions are released
to machines and when.

In the past I've handled similar problems by using chroots of different
OS releases to seperate application environments. There can be
maintenence issues and it's not the cleanest way to do things, but it
worked. I wrote some scripts to copy things in to the right places and
before and after proccessing. You can probably run into library trouble
doing that (glibc come to mind for some reason), but I've never had an
issue.

For certain apps (mediawiki, groundworks) there are entire environements
wrapped up in 1 package with all of it's dependencies for you to
download an install.

The other road you can take is paying for support to either a vendor
(e.g. Suse, RedHat), or an independent contractor to handle making
packages for these platforms for you. And I'm sure alot of developers
wouldn't mind an extra couple bucks to backport their app to an older os
if you contacted them. 

If you have custom packages made or make them yourself, I'd encourage
you to distribute them back to their maintainer or post them on a
website. Chances are if you are looking for the new release Joe's Sweet
Shiney Widget Parser for RHEL3, chances are someone else is. Next time
maybe they will do the heavy lifting, or the maintainer will add it into
list of targets.

Pick your poision, but I'd aim for seperation and segmentation.

Best
Patrick 

-----Original Message-----
From: gnhlug-discuss-bounces at mail.gnhlug.org
[mailto:gnhlug-discuss-bounces at mail.gnhlug.org] On Behalf Of Charlie
Farinella
Sent: Tuesday, May 15, 2007 12:12 PM
To: gnhlug-discuss at mail.gnhlug.org
Subject: Re: Package management

On Tuesday 15 May 2007, Neil Joseph Schelly wrote:
> On Tuesday 15 May 2007 11:34, Paul Lussier wrote:
> > Bah!
> >
> >  $ apt-get source foo=<desired package number>  $ cd foo-<version 
> > number>  $ dpkg-buildpackage -rfakeroot  $ cd .. && dpkg -i 
> > foo-<version number>
> >
> > This will compile the source for whatever version of the debian 
> > package foo you need against your installed library base, create a 
> > package for it, then install it.
>
> Bah back at you.  That was my option 3.
>
> > 3. Third, I'll try a backport myself.  This really depends on the 
> > package in question and what library requirements it will have.  I 
> > download the source package from a newer OS version (in your case, 
> > the next release of CentOS) and I try to compile it for the local 
> > system, so I can at least keep my repository dependencies usage 
> > consistent.
>
> That said, my option 3 didn't have that much detail and didn't make so

> light of the potential library requirements a newer version may have, 
> because I didn't want to detail the Debian/APT commands here that are 
> useless to the CentOS installation at hand.
> -N

Just to be clear, my question only uses CentOS/Python as an example and
is not the precise problem I want to solve.  I want to pick a
distro/procedure and stick to it based on solving this kind of problem.

Thanks for the feedback.  :-)

--charlie

--
------------------------------------------------------------------------
Charles Farinella
Appropriate Solutions, Inc. (www.AppropriateSolutions.com)
cfarinella at AppropriateSolutions.com
voice: 603.924.6079   fax: 603.924.8668

_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss at mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/