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