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

Panu Matilainen pmatilai at laiskiainen.org
Thu Feb 26 21:49:58 UTC 2009


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 -




More information about the devel mailing list