Fedora 11 Mass Rebuilds

[Panu Matilainen]

On Thu, 26 Feb 2009, Mike Bonnet wrote:

> Panu Matilainen wrote:
>> On Tue, 24 Feb 2009, Tom Lane wrote:
>>
>>> Jesse Keating <jkeating at redhat.com> writes:
>>>> On Tue, 2009-02-24 at 16:32 -0700, Orion Poplawski wrote:
>>>>> Can you say what it is?  I'm seeing this on my centos 5.2 mock host.
>>>
>>>> The rpm version on the host has to be able to support the larger file
>>>> checksums.  We have a special rpm built for our EL5 builders that
>>>> provides this.  I don't know if that rpm build is hosted anywhere out in
>>>> the open, I do believe Mitr built it for us.
>>>
>>> It's going to be quite a large problem if people can no longer use mock
>>> on an older system to test rawhide builds.  What is the plan to address
>>> this?
>>
>> The strong file hashes are just the first messenger that got through,
>> and the message it brings is that it's time for people to wake up from
>> the sleep of last hundred, err, ten years and realize that rpm can and
>> does change. And yes it means older rpm versions can't always install
>> packages built by a newer rpm.
>
> In the future can we make it policy that before any new,
> non-backwards-compatible rpm features are turned on in the build system,
> that all actively-supported distros have an rpm that supports those
> features available in the stable repos for a reasonable period of time?

What does "actively supported" mean here? By gods I hope you're not 
including RHEL here. If that's the case the rpm team might as well take a 
very long vacation...

That rpm 4.6.0-rc and 4.6.0 final had an incompatibility wrt the strong 
hashes was most unfortunate (and so was the timing of mass-rebuilds 
starting before the update fixing that was got deployed), I sure hope such 
a thing wont happen again.

> Not being able to install packages coming out of Koji has a very
> negative effect on development, testing, package review, etc.  We also
> want to avoid the situation of people running actively-supported distros
> being permanently locked-out of the ability to update or upgrade, if for
> example the rpm in the repos was built using a feature that the previous
> version of rpm did not support.

Obviously rpm needs itself needs to be upgradable to next version, no 
matter how painful it may be.

> rpm is a critical (maybe *the* critical) piece of our
> installation/upgrade infrastructure, we need to be more careful with
> compatibility.

We take compatibility dead seriously, but there are very real limits to 
what can be done compatibly and what can be be reasonably backported, if 
possible at all. The strong hash support might be within possibilities but 
already in rpm 4.6.0 the large package support is something that is 
*impossible* to backport due to the required API/ABI changes.

 	- Panu -