Call for comments - RPM upgrade

[Warren Togami]

Please DO NOT cross post this thread to other lists.  It only confuses 
the issue when different parts of the discussion inevitably end up in 
different places.

Jesse Keating wrote:
> No one person.  It's a community thing.  Sure I'm the guy in the lead 
> right now, but I don't get to set policy myself, that'll drive people 
> away.  We need to start a new thread on this subject.  Warren, you had 
> a good suggestion to bump people up to the latest on rpm.org for each 
> given distro.  I can see this for 8.0 and 9, which had some nasty lock 
> bugs, but what of 7.2 and 7.3, is it really necessary?

It is my opinion that RH8 and RH9 should be upgraded to the latest 
versions for the respective distros.  Regarding Barry K. Nathan's 
concern about the epoch promotion problem, could you please post a 
concrete example of what triggers that problem?  The entire list needs a 
refresher about exactly what this problem is.

(Also I believe there was some config option that we could toggle to get 
the old epoch behavior back.  We will determine through your concrete 
example and further discussions if switching this option will be needed.)

We should eventually put up 7.2 and 7.3 for a vote after we have a 
thorough analysis of the technical improvements in the latest rpm-4.0.5 
release.  It is true that RPM was less problematic back then, but my 
main concern is the broken nature of rpmvercmp in those older versions. 
  In those old versions, whenever rpm compared a number to a letter, or 
letter to letter, it would trigger the "two way upgrade" problem which 
is bad.  Additionally rpm-4.0.4 had *some* deadlock issues that are 
probably gone in the upgrade version.  (Do testing.)

Before ANY rpm upgrade happens, we will need to do much testing if the 
RPM upgrade breaks any 3rd party tools including apt-get, yum, Red 
Carpet and perhaps others.  In some cases users may need a compatibility 
library like the rpm 404 compat library provided with the rpm-4.1.1 
upgrade for RH8.

Two more long term notes:
1) Some have suggested a rewritten rhn_applet and up2date for RH7.3, RH8 
and RH9.  They suggested that after RHN stops providing software update 
services, perhaps a community based notification service could take its 
place.  I personally think a centralized service may have trust issues 
like "would you trust your server package information with total 
strangers?"  The next best thing would be a host-based service that 
daily checks for updates, then sends notification e-mail to the sysadmin 
if updates are available.  The notification e-mail recipient address and 
possibly SMTP server would then be configured during firstboot and 
System menu.

2) Before I forget about this... in our RPM upgrade instructions for RH8 
and RH9, the docs should mention turning off all services that could 
cause RPM database contention.  That would mean the RHN applet, rhnsd, 
Red Carpet's daemon, yum's cron thing, or anything else that could 
possibly touch the RPM database during rpm upgrade.  This would lessen 
the chance of RPM deadlocking during the rpm upgrade.  After the upgrade 
it can be safely turned on again.

Warren Togami
warren at togami.com