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@xxxxxxxxxx
