From Bugzilla Helper:
User-Agent: Mozilla/4.74 [en] (X11; U; Linux 2.2.17pre18 i686)
Currently have RPM version 3.0.2. Can't install rpm-4.0-4.i386.rpm because:
# rpm -Fvh rpm-4.0-4.i386.rpm
only packages with major numbers <= 3 are supported by this version of RPM
Can't install rpm-3.0.5-9.6x.i386.rpm because:
# rpm -Fvh rpm-3.0.5-9.6x.i386.rpm
error: failed dependencies:
bzip2 >= 0.9.0c-2 is needed by rpm-3.0.5-9.6x
libbz2.so.0 is needed by rpm-3.0.5-9.6x
Have bzip2 1.0.0 installed on system from tar, but the libbz2 files from it
are not compatible with < 1.0.0. I don't see a bzip2 0.9.0c-2 rpm on your
ftp site, although there are some 0.9.0b-1 compilations for libc5 under
contrib, which wouldn't be the right thing, right?
Can't get a tarred sourch of the current rpm program because your own rpm
HOWTO on your Website links to a version several years old rather than
Suggestion: why not just package the current version of RPM so that it is
compatible with previous versions, at least as an option for 6.0 and prior
Red Hat users - and make sure it doesn't have dependencies on anything
(like bzip2) whose recent versions require a recent version of rpm itself
to install? Also, especially if you don't take the first suggestion, it
would be good if you posted a current tar of rpm in a prominent place so it
can be built in the traditional way.
Steps to Reproduce:
The errata for rpm-3.0.5 was built against released updates and errata for 6.x.
rebuild rpm-3.0.5 against your bzip2 package, or downgrade to the bzip2 package
shipped with Red Hat 6.x.
Source rpm's were released with the rpm-3.0.5 errata. You can find tarballs and
for all releases of rpm at
Thanks for the direction to the tarball. I suggest that the link from your
HOWTO, which is itself prominently linked from one of your pages, should be to
ftp.rpm.org rather than the obsolete version on one of your servers, and that it
is something of a site bug not to have it so.
I also suggest that you could save many users of Red Hat 6 the difficulty of
'rebuilding' the rpm (or finding a particular antique version of bzip2 for only
the sake of an intermediate upgrade) by simply following the common sense of
always providing RPM itself in an rpm package that can be used by older versions
of RPM. It would be much easier for you to do this once, than for those in the
field to have to go through contortions to upgrade this one, most essential tool
for maintaining their Red Hat installations. Can you please consider this
feature request that would earn Red Hat good will from the community?
My sense is that most people don't rebuild rpms - if the rpm is too foobared to
install easily, most sysadmins grab the tarballs. So it's fairly important to
(1) have rpms for something as vital as RPM that install cleanly on the widest
range of systems and (2) always point prominently to the home of the tarballs
for when they fail. So again, please consider adding the feature of maintaining
a version of the RPM rpm that will work with older versions of RPM.
FWIW, rpm is always available for legacy platforms in legacy compatible
The real issue, in your case, is that there isn't an upgrade/errata for bzip2
for legacy platforms, as there has been an incompatible change in the bzip2 API
between Red Hat 6.x and Red Hat 7.0.
Finally, rpm doesn't make any serious use of bzip2 anyways, bzip2 is both memory
and cpu resource intensive, like 5-7 times more than gzip. One can argue for
bzip2 from rpm entirely. That's basically the reason why an errat/update has not
made for bzip2 on legacy Red Hat platforms.
"rpm is always available for legacy platforms in legacy compatible packaging"
Wouldn't the straightforward answer be to offer an rpm of RPM 4 that works with
RPM 3.0.2, for instance, and presents the message "for full functionality,
install the rpm of bzip2 1.0.1 next"?
One last question then (since I've just spent time trying to get RPM 4 to
compile from the tarball, and despite carefully following the sequence in the
instructions and checking that the Makefile seems to point to everything
correctly, it fails in the same way for either gcc version 2.95.2 or gcc22.214.171.124
-- which suggests the instructions aren't quite complete?) ... where is the
rpm-4.0 file that I can install from rpm 3.0.2 with --nodeps to ignore the bzip2
thing? Or will doing a --nodeps on 3.0.5 then give me an rpm that can install
4.0? And it won't end up breaking anything that matters to not have bzip2
support? If you're not building bzip2'd rpms, I don't care about opening them.
Sure would be nice if those failed dependencies flags had notes attached like
"this one doesn't matter, feel free to override." Otherwise there's this fear
like "an override here could break a really important utility." Seems like it
would be real useful if rpms were built not just to list failed dependencies,
but to show a small installation note about whether and how each of them
mattered. Because some are fatal, and others can be for stuff that'll never make
Or even better, I know bzip1.0 changed the API from 0.95 -- is all that rpm 4.0
needs for full functionality to find the bzip files in a certain place? Where?
(If this is the case, a dependency message that said "bzip2.rpm not installed,
but if you have bzip2 1.0 installed in /dir use --nodeps & yr ok" could be quite
useful. See Petreley's recent discussion of the desire for update tools that can
cooperate both with installed packages and installed tarballs.)
My outsider opinion is still that rpm is too important a package to have it
hostage to _any_ dependancies that can't be easily satisfied (and even the bzip2
0.95 rpm won't install from rpm 3.0.2 -- and it has the old API which should
work for 3.0.5, right? but you can't install it to get 3.0.5 to work ... and I
really don't know where my RH 6.0 CD went [having not had any reason to install
from it since 6.1 and 6.2 came out] so since you don't have it online anymore I
really don't have access to the peculiar version of bzip 0.90 that you've got
rpm 3.0.5 depending on ...). The true 'legacy compatible' package would be an
RPM 4 rpm that can be installed by RPM 3.0.2, for instance, without a dependency
like 'installation must have included what was an obscure, minor package at the
time, with no installation of a later version since from either rpm or tarball.'
Instead, RPM 4 can't be installed _at all_ from 3.0.2 directly, right?, unless
there's a special rpm of it somewhere obscure.
Q: RPM 4 can't be installed _at all_ from 3.0.2 directly, right?
A: rpm is always available for legacy platforms in legacy compatible
For the 3rd time, your problem is that you have chosen to upgrade bzip2 with
an incompatible soname.
"A: rpm is always available for legacy platforms in legacy compatible
Well then, where is the version in the 'legacy compatible packaging'? If you
will read back to the beginning of my initial report this is what happens with
an attempt to install rpm-4.0-4.i386.rpm using rpm 3.0.2:
"# rpm -Fvh rpm-4.0-4.i386.rpm
only packages with major numbers <= 3 are supported by this version of RPM"
That says pretty clearly that rpm-4.0-4.i386.rpm is not a legacy-compatible
package - this is not a dependency failure; this is an inability of rpm 3.0.2 to
even open the package. Surely you have an option to build a package so it is
compatible with earlier versions of rpm for installation? And if you haven't
done that, then how can you claim there is a 'legacy compatible package'?
The compatible package is not at
http://www.redhat.com/support/errata/rh60-errata-general.html - which would be
an obvious place to put it, right? So if it's available, where is it? Why isn't
it in any obvious place? I can always use --nodeps if the only glitch is bzip2
support, and if as you said that doesn't really do much.
You are installing a 7.0 package on a 6.2 box. The legacy compatible packages
are at ftp.rpm.org and will install with any version of rpm back to rpm-3.0,