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). -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
