Heads up for rawhide users: if you missed an update, you're stuck

[Mike Bonnet]

Panu Matilainen wrote:
> On Thu, 26 Feb 2009, Jason L Tibbitts III wrote:
> 
>> Just a note to rawhide users who don't update every day: if you missed
>> the upgrade to rpm-4.6.0-8.fc11, you now cannot read many (and soon
>> all) packages in rawhide, including the current version of the rpm
>> package.  I believe there was a two day window to do this, so if you
>> haven't updated since Tuesday you might be stuck.
>>
>> To get going again, visit koji and manually download the -8 packages
>> for your arch, update them manually, and then let yum update you the
>> rest of the way.
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=83804
> 
> This is just totally bogus.
> 
> Rpm 4.6.0 final, which has been in rawhide since Februare 6th, and
> recently submitted to F10 as update can handle the new packages just
> fine. Only the 4.6.0-rcX versions cant cope.

I will note that F11 Alpha contained rpm-4.6.0-0.rc3.2.fc11, so a fresh
install of the alpha can not be updated.

I don't think people realized how significant a change building with
larger hashes was, and that it would make packages uninstallable on
older versions of rpm.  If that was there in the release notes and
people involved with Fedora Infrastructure (myself included) failed to
take note of it, then that's our fault.  Please don't consider these
discussions a personal attack Panu, rpm development is a beast and you
guys are doing great work.

I think the upgrade to larger hashes would have been handled much better if:

 - Versions of rpm supporting installation of larger-hash packages were
in the stable repos of all actively supported distros (F9, F10, rawhide)
for a reasonable amount of time (a couple weeks, at least) before
turning that feature on in Koji.

 - We had a test plan in place to test upgrade from older versions of
rpm to newer.  A "mock --init" of a rawhide buildroot on every supported
OS should probably be part of that test plan.

Developers, testers, and package maintainers are a significant portion
of the Fedora community, lets do everything we can to not break an
important development tool they use, or if it can't be avoided to
communicate it better beforehand.

If incompatible rpm changes are going to become more frequent, perhaps
we should have a yum plugin installed by default that, when a rpm
(and/or yum?) update is available, will update rpm/yum first and re-exec
yum.  It may avoid the problem of people getting halfway through a
transaction and then hitting errors.

If we can learn from this experience of rolling out an incompatible rpm
change, we can make the process less painful next time we roll one out
(larger packages, 4096-bit GPG sigs, etc).