Yum, autoupdate

[James Olin Oden]

On 29 Jul 2003, Jeremy Portzer wrote:

> On Tue, 2003-07-29 at 20:39, James Olin Oden wrote:
> >  But, as an example, on our platforms we have a file
> > that contains the current platform version (similar to redhat-release
> > but different...).  We don't do an upgrade if the platform version on the
> > system is greater than the platform version we are installing.  In order
> > to do something like that with yum, we would need a hook to do some
> > sort of prevalidation.  
> > 
> > We would need another hook before and afterword to run arbitrary scripts
> > (but not for validation purposes).  Right now we deliver a lot of rpms
> > that make various changes to config files.  In these rpms we check the
> > files out via rcs (well a wrapper I wrote), make the changes, and then
> > check them back in.  Course not everything on the system is using rcs
> > when it changes config files.  To fix this we run a script that finds
> > every config file that has an element in its repository and see if what
> > is in the filesystem differs from the most current version in the 
> > repository.  If it does then we check those changes in as the latest 
> > version.  We need to do the same thing afterward, because, obviously
> > we can't expect RedHat to make their rpms use our wrapper (-;.
> > 
> > So just there, without thinking too hard (it hurts (-;), you have
> > three hooks needed:
> > 
> > 	- one for validation before hand.
> > 	- one to run general purpose scripts before the rpm transaction.
> > 	- one to run general purpose scripts after the rpm transaction.
> > 
> 
> Wouldn't it be more straightforward to make 'dummy' RPMs that use the
> provides/requires capabilities to provide this sort of validation, and
> then use appropriate %pre and %post scripts in the RPMs?
No.  That is the simple answer.  The pre approach for validation is 
not really a good idea, because at that point you have already started
an rpm transaction rolling along.  The idea of any sort of validation is
to as _early_ as possible determine if an upgrade should occur at all.
Yum already does this, to the extant that it figures out if any rpms
need to be installed or not.  This would just be a natural extension of
that.

>  For example,
> you could have a "platform-release" RPM that requires all the packages
> that you're trying to install.
Well, if your doing an upgrade, yum is already smart enough to check the
rpms on your system against the ones it was provided to install.  So 
some super package is only good for creating clusters (i.e. give yum
one rpm that will by dependencies cause a complete cohessive set of
rpms to be installed).

>  This would have a %post script that
> would execute the necessary checkins you refer to. 
That won't work because things occur like this:

	- All installs are done.  For each individual package that is 
          installed is sent through the rpm psm (package state machine) 
          which does per package:
		
		- Run %pre
		- Install %files payload
		- Run %post
	- All erases occur.  Each erase goes through the psm:
		- Run %preun
		- Remove files that are only part of the erased package
		- Run %postun

And don't forget erasures are not sorted.  Anyway, the point of all that
is that if the thing is installed first to validate, it can't be used
to do things at the end of the transaction.  If its installed last,
it can't be used to validate.


> Because of the
> automatic ordering that RPM installations perform, the
> "platform-release" %post should run after all the require'd RPMs get
> installed, unless I'm misunderstanding something.
Yes you are (don't worry though, I am still purchasing clues from
Jeff Johnson, Seth Vidal, and all the other rpm cronies (-;).

> 
> Maybe that won't work in your situation, but it seems to me that since
> RPM already has all of this complexity and extensibility, you should use
> it there, instead of adding duplicate code to yum.
RPM is _very_ complex, and I believe for good reason.  At the same time
RPM is very simple in that it manages packages (not really files...but
ask Jeff Johnson about that, as I am still trying to get that clue (-;).
The sort of things that I am wanting to do is clearly outside of 
rpm, and should not try to be grafted in (I already do to much of that
as it is by using rpm's to install config file changes).  Really, 
to halfway quote Jeff, I am looking for policy implementation, which
needs to for the most part stayout of rpm, and in the programs that
use rpm implement those policies.

Cheers...james 
> --Jeremy
> 
>