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