On Thu, 26 Feb 2009, Mike Bonnet wrote:
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.
Ugh. Ok I missed that point, thinking just "well rawhide is rawhide and
every rawhide user updates at least once a week so whats the problem?"
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.
Indeed. Like I said in some earlier mail around this topic, rpm has been
standing still for so long that nobody realized/remembered the full
consequences of such changes. The previous change of similar scale has
been somewhere in rpm 3.x -> 4.0: anybody still remember the
"rpmlib(CompressedFileNames) <= 3.0.4-1 is needed by ..." errors way back
back then?
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.
No offense taken, and besides I certainly deserve my share of the lumps
for the mess.
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.
F9 is really the pain-point here due to the huge jump in rpm (having
been there, I do not want to have an update that big ever again, which
is part of the reason for wanting 4.7.0 now), backporting large changes
such as the strong hash support is not only very painful but risky too.
- 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.
The kind of incompatible change that rpm 4.6.0-rc -> 4.6.0 final had is
not going to happen again, I certainly hope to have learned a lesson or
two from that "episode." New things depending on rpmlib(foo) features
that older versions dont provide are to be expected though, sooner or
later.
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).
Nod, this is probably best taken as a lesson how not to do things :)
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
