This is a repost. I think my original was lost because
I sent it with the wrong from address.
On Tue, May 01, 2007 at 08:35:53PM -0600, Wayne Sweatt wrote:
> If I have 4 or 5 versions of say pgi or intel compilers that I need to
> make available on a compile server, and each version installs into it's
> own directory tree, such as /opt/PGI/6.7.8 & /opt/PGI/6.7.9 , etc...
> then can yum do this? Will it complain and/or try to upgrade?
It will try to upgrade unless:
> Would I use installonly?
Yes, installonlypkgs in yum.conf actually.
> How do I do this?
> There would be no conflict per se, and I've been doing this with rpm, and
> wish to move to yum.
You can with the caveat that your package has no way to tell if it is
being installed or upgraded, so it can't abort it's install if it is
being upgraded. That was a requirment in my rollout, and I haven't
been able to modify the yum core or figure out how to make a plugin
that tells the rpm what mode it's being installed in.
Sadly if the yum.conf file on your client has a typo or something (in
the installonlypkgs directive) that causes your package to be upgraded
rather then installed, all the info about the other versions of the
package is wiped from the rpm database. The files still exist on disk,
it's just that you can use rpm to find out what was installed. Since
we have dozens of packages that need to be installed, it's easy to
typo that line or forget to add a package.
We use a DepotLite format for our packages, we can usually clean up
from this and remove the older packages using
rm -rf /tools/package-ver
Your's seem to install into /opt/PGI/... so you can clean up in the
same way. If your packages install into the /usr tree and have
versioned directories under there, cleanup is a mess.
In either case, using rpm to audit the installed software is useless
after a package is upgraded that should have been installed.
You can't use the value passed in to the pre scriptlet to determine if
this is an upgrade or an install as:
$ sudo rpm -i rpm_test-1.0-1.rpm
has the installed count (from rpm -q package_name| wc -l) = 0
has argument passed to %pre scriptlet = 1
$ sudo rpm -i rpm_test-2.0-1.rpm
has the installed count (from rpm -q package_name) = 1
has argument passed to %pre scriptlet = 2
now it gets interesting:
$ sudo rpm -U rpm_test-4.0-1.rpm
has the installed count (from rpm -q package_name) = 2
has argument passed to %pre scriptlet = 3
so it looks like there should be three copies of the installed package
when the current upgrade finished, except:
$ rpm -qa | grep rpm_test
returns
rpm_test-4.0-1
after having installed using upgrade rpm_test-4.0-1. Note I am using
rpm for this example, but yum has to provide exactly the same info to
the scriptlet otherwise it's a bug. Also I verified this with yum a
while back (prior to a December email), and ran the rpm example just
now to make sure I got it right.
So the only way to really make sure that packages won't be lost from
the database is to check the install mode in a pre-scriptlet. With
rpm, you can search for the parent process of the pre scriptlet and
look for -i or --install on the command line. In yum there is no such
method.
So if somebody screws up the yum conf file and you accidently get an
upgrade rather then a true install... well it's bad.
My idea was to set an environment variable YUM_MODE='install' or
'upgrade' as each package is installed that is available to the
scriptlets so it could easily check to see what mode it was being
installed. However I haven't had any luck doing that either with the
core code or via a plugin in the pretrans_hook.
I think the pretrans hook should work as I think it is called for
every package that is up be upgraded (c.f. rpm's pretrans scriptlet),
but it's not explicit from the documentaion
http://wiki.linux.duke.edu/WritingYumPlugins what the scope of the rpm
transaction is, I assume package by package.
So if anybody has any ideas on making this possible I would appreciate
it.
I have a couple of short email chains on this as well:
https://lists.dulug.duke.edu/pipermail/yum/2006-November/009336.html
https://lists.dulug.duke.edu/pipermail/yum/2006-October/009195.html
--
-- 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
