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