RHN Updates

[James Olin Oden]

On 6 Aug 2003, Matthew Winter wrote:

> Jef Spaleta wrote:
> >Gilles J. Seguin wrote, somewhere in the digest:
> >>The third item require that peoples with a minimum of training
> >>be able to install and play with a package.
> >
> >Yes i understand that submitting useful bugreports doesnt take much in
> >the way of training...neither does breaking a working system, without
> >fully understanding the consquences of your actions :->
> >
> >But I'm more concerned about getting into a situation where the
> >convience tools...the point and click tools like up2date...start
> >getting features where people can easily install 'testing' packages
> >on top of full releases..without having to stop and think about what
> >they are doing...when they have no intention of actually being a part
> >of the testing process...and don't have a clue about how to recover if
> >the testing packags are broken.
> 
> If RHN was providing the means to upgrade to a 'test' version of the
> software, it could also provide the means for the use to return to their
> prior release of the software, so making the recovery process straight
> forward.
>
This assumes that the testing packages have no bugs in their packaging.
If a package has bugs in its scriptlets, then you can end up with a mess
that is near impossible to fix in an automated way.  Their two places 
where this is really appearant:

	- A %post scriptlet dies under some condition.
	- A %postun, or %preun dies under some condition.

In the first case in the least you end up with two headers on your system
one for the package being installed (the new version in a normal upgrade)
and one for the package that was going away (the old version in a normal
upgrade).  A simular thing happens with with the package being erased
in the case of uninstall scriptlet failures.  This of course only deals
with problems with the scriptlets themselves and the state of the rpm
database.  There can be any number of other errors that can occur that
don't backout very well out all.  

The issues a test/development rpm is called that becuase it has not been
tested to the degree that one of the rpms from an official release has 
been tested.  Note, doing an install is not a sufficient test, you 
have to also test it in a rollback.  Furthermore, sometimes the bugs 
are in the older blessed packages scriptlets (and this is pain), such
that the test script may have to bring with it some hackage to work
around the previous scriptlets foibles.  

Anyway the bottom lines, expecting to be able to go back from a test
system is unreasonable.  If you want to test this, that is reasonable
and a service to everyone, but expecting things to just work is a 
bad assumption.

Cheers...james