Fedora 11 Mass Rebuilds

[Jon Ciesla]

Mike Bonnet wrote:
> Panu Matilainen wrote:
>   
>> 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...
>>     
>
> No, in this case I mean F9, F10, rawhide.  It's unfortunate that rawhide
> packages are no longer installable on F9, and were not installable for a
> while on F10.  This negatively affects developers, testers, etc.
>
>   
>> 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.
>>     
>
> I understand things got rushed because of the timing of the mass
> rebuild, which got rushed because of the timing of the feature freeze.
> I'm not trying to lay blame on anyone, just pointing out that we need to
> think about the process of rolling out new, incompatible features when
> they affect the installation/upgrade path, be they rpm, yum, anaconda, etc.
>
>   
There's my next question.  Will an upgrade from 10 to 11, whether by 
anaconda or yum, be possible?


>>> 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.
>>     
>
> Agreed.
>
>   
>>> 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.
>>     
>
> I don't know anything about large package support.  Is this something
> that will affect the package installation in Fedora?
>
>   


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie