On Wed, May 02, 2007 at 01:31:38PM -0500, Michael E Brown wrote:
> On Wed, May 02, 2007 at 02:26:05PM -0400, John Rouillard wrote:
> > Sadly it doesn't support most depot models where multiple versions of
> > the same software are available on the host at the same time. You can
> > verify from the rpm that it is being installed is you use rpm but not
> > yum.
>
> Fundamentally, if you want to install multiple versions of a single
> package, the best way to do this is via:
> packageV1-1.0-i386.rpm
> packageV2-2.0-i386.rpm
> packageV3-2.0-i386.rpm
>
> rather than:
> package-1.0-i386.rpm
> package-2.0-i386.rpm
> package-3.0-i386.rpm
>
> Especially if you want to do this on a regular basis. This allows very
> easy co-existence of the packages without resorting to any special
> hacks.
Yeah I know that's the way people do it and IMO it's broke.
The reason it works is because you aready did the 'special hack'. The
'special hack' is to create different software packages (by embeding a
version id) just because you need to install multiple versions of a
single package.
Now 'rpm -q package' doesn't work to list all the versions of the
package that are installed, you need to know before hand what versions
of what packages are installed to find out what version of what
packages are .... well you get the idea.
'rpm -qa | grep package' works, but is slower than 'rpm -q package',
and can end up matching more than you intended to so it is somewhat
tricky to use for automatic maintainance and deployment from another
tool like cfengine, puppet, bcfg2 or Config.
I know that's the hack that is used, I just find it annoying when you
are trying to maintain/inventory/audit lots of packages on lots of
machines.
> Another model that works (similar to gcc/libstc++):
> package-3.0-i386.rpm <-- latest
> compat-package_v1-1.0-i386.rpm
> compat-package_v2-2.0-i386.rpm
>
> This allows people that always want latest to automatically get upgraded
> to latest and greatest, while people can co-install all of the older
> versions easily.
Yup, you have the same verion querying issue. Plus by changing the
name of the package you may have to go to rpm to tell what file
belongs to what package. Because the paths to the file in the
compat-package_v2-2.0 must not change in name from when they were
deployed as part of package-2.0-i386.rpm, otherwise you have to
relink/change the software that uses the new compat packages.
Shared objects that have a built in versioning mechanism allow this
easily, but config files and programs and other resources don't
generally support that.
Also in DepotLite or other depot like packaging schemes (e.g. /opt)
there is usually a one to one correspondance between the install path
and the package name. E.G.
Path Package
/tools/subversion-1.4.3/... subversion-1.4.3
/tools/subversion-1.3.2/... subversion-1.3.2
which can work across systems. I have had DepotLite configs on 9
different os's from solaris to bsdi to irix and it make a very
consistant environment for my users (and the admins).
What's funny is that RPM is fine with installing both:
subversion-1.4.3
and
subversion-1.3.2
and properly reporting the files associated with each etc. Just don't
upgrade a package and keep installing and erasing them and all is
well. I am not sure if this is by design or accident however.
--
-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111
_______________________________________________
Yum mailing list
Yum@xxxxxxxxxxxxxxxxxxxx
https://lists.dulug.duke.edu/mailman/listinfo/yum
