This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
===
Subject: RPMs - Frustration sets in.
From: Ward William E PHDN <wardwe@nswcphdn.navy.mil>
Date: Wed, 1 Mar 2000 08:52:36 -0500
Ok, so I have to do a Microsoft and reinstall RH6.1 since the RPM database
has become corrupted and no one seems to know how to fix it.... I can deal
with that. Now I'm having problems with my other 6.1 system and the RPMs,
but this is a side effect of the developers getting careless, it appears.
I've tried using AutoRPM to update the installed base on system to the
latest patch levels, and I get the following:
---------------------------------------------------------
** Failed RPMs **
libxml-devel-1.7.3-1 is missing dependencies:
libxml = 1.7.3
libgtop-1.0.5-1 is missing dependencies:
libgtop = 1.0.3
libgtop = 1.0.3
gtk+-devel-1.2.6-1 is missing dependencies:
gtk+ = 1.2.6
libglade-0.7-1 is missing dependencies:
libglade = 0.6
libgtop-examples-1.0.5-1 is missing dependencies:
libgtop = 1.0.5
gnome-games-devel-1.0.51-3 is missing dependencies:
gnome-games = 1.0.51
ORBit-0.5.0-2 is missing dependencies:
ORBit = 0.4.95
gnome-games-1.0.51-3 is missing dependencies:
gnome-games = 1.0.40
libxml-1.7.3-1 is missing dependencies:
libxml = 1.4.0
libgtop-devel-1.0.5-1 is missing dependencies:
libgtop = 1.0.5
pygnome-1.0.50-2 is missing dependencies:
pygtk = 0.6.3
gtk+-1.2.6-1 is missing dependencies:
gtk+ = 1.2.5
libglade-devel-0.7-1 is missing dependencies:
libglade = 0.7
ORBit-devel-0.5.0-2 is missing dependencies:
ORBit = 0.5.0
control-center-devel-1.0.51-1 is missing dependencies:
control-center = 1.0.51
gnome-core-devel-1.0.54-2 is missing dependencies:
gnome-core = 1.0.54
gnome-libs-devel-1.0.54-1 is missing dependencies:
gnome-libs = 1.0.54
control-center-1.0.51-1 is missing dependencies:
control-center = 1.0.40
gnome-core-1.0.54-2 is missing dependencies:
gnome-core = 1.0.39
gnome-libs-1.0.54-1 is missing dependencies:
gnome-libs = 1.0.40
Interactive-Install Queue:
22 RPM(s) waiting to be installed/updated Interactively
To install/upgrade, run 'autorpm --apply' as root...
---------------------------------------------------------------------
Ok, if AutoRPM can't find those automatically, the easiest thing to do is
check Freshmeat or Redhat and try to find the missing RPMs so that I can
solve the missing dependencies problem... and they seem to come down,
basically, to gnome-libs-1.0.40-1.i386.rpm being the missing culprit
(it gave many of the other libraries that are mentioned). Fine, I'll
track down a copy, and install it.... yes, I know, that was a development
version... but no, you can't GET that version now... yet the current
NON-development versions require it. They don't think about the fact that
folks will be starting and trying to upgrade from fairly old (the original
6.1 install RPMs) to up-to-date (i.e. gnome 1.0.54 or 1.0.55) without
having access to the intermediate steps... I mean, on an operating system
where some folks are still happily sitting back at 4.1 and 4.2 when 6.2 is
imminent, you'd think folks would keep the old RPMs available </rant>.
Ok <breathing, calming> Anyone out there have a solution to this dilemma?
I want to try to get the box up to latest and greatest standards... and
this is frustrating as can be.
===
Subject: Re: RPMs - Frustration sets in.
From: lloy0076 <lloy0076@rebel.net.au>
Date: Wed, 01 Mar 2000 12:58:02 +1030
HEHEHE
I avoid use RPM as much as I can. If I ever use it I always use --force.
The RPM database seems to fall over even worse then the Windows Registry
if I may say so myself. It's good for a system where ALL YOU EVER
install is RPM'ed, and it's on high reliability but other than that it's
caused me far too much grief to be bothered.
I don't try to pretend that Linux is Windows and just use make and
./configure.
DAVID
===
Subject: RE: RPMs - Frustration sets in.
From: Ward William E PHDN <wardwe@nswcphdn.navy.mil>
Date: Wed, 1 Mar 2000 09:49:04 -0500
You obviously missed my post earlier about how when I try to use
rpm on one of my systems, it appends a leading / to the front...
so that it is trying to constantly update //var/spool.... as
opposed to /var/spool.... and that rpm --rebuilddb doesn't work
for the same reason....
I asked for help there, too... I've read the man pages, read the
FAQ, read the How-to.... and nothing seems to point to how to fix
that.
Just because you've been having success with RPM doesn't mean that
it is bug free... that's a HUGE bug, and I've yet to see someone
say how to fix it, but it has now hosed an >OTHERWISE FINE SYSTEM<
to the point I have to Microsoft and do a complete reinstall...
So, Mr. Guru, I await.... I haven't reinstalled the system (intend to
do so today)... how can I save Linus? And how do I get these old
RPMs for Charlie so that I can get it up to snuff? If you know the
answers, please tell me.
===
Subject: Re: RPMs - Frustration sets in.
From: lloy0076 <lloy0076@rebel.net.au>
Date: Wed, 01 Mar 2000 13:41:49 +1030
I disagree. Using ./configure and make on a source distribution
discovers many more errors that RPM can simply miss or gloss over. Each
to one's own I guess...such is the power of Linux.
===
Subject: Re: RPMs - Frustration sets in.
From: Rick Forrister <rickf@crow.jpl.nasa.gov>
Date: Wed, 01 Mar 2000 08:14:40 -0800
wardwe@nswcphdn.navy.mil said:
> Ok, so I have to do a Microsoft and reinstall RH6.1 since the RPM
> database has become corrupted and no one seems to know how to fix
> it.... I can deal with that. Now I'm having problems with my other
> 6.1 system and the RPMs, but this is a side effect of the developers
> getting careless, it appears.
> I've tried using AutoRPM to update the installed base on system to the
> latest patch levels, and I get the following: -------------------------
[snip]
> Ok, if AutoRPM can't find those automatically, the easiest thing to do
> is check Freshmeat or Redhat and try to find the missing RPMs so that
> I can solve the missing dependencies problem... and they seem to come
> down, basically, to gnome-libs-1.0.40-1.i386.rpm being the missing
> culprit (it gave many of the other libraries that are mentioned).
> Fine, I'll track down a copy, and install it.... yes, I know, that
> was a development version... but no, you can't GET that version now...
> yet the current NON-development versions require it. They don't think
> about the fact that folks will be starting and trying to upgrade from
> fairly old (the original 6.1 install RPMs) to up-to-date (i.e. gnome
> 1.0.54 or 1.0.55) without having access to the intermediate steps... I
> mean, on an operating system where some folks are still happily
> sitting back at 4.1 and 4.2 when 6.2 is imminent, you'd think folks
> would keep the old RPMs available </rant>.
> Ok <breathing, calming> Anyone out there have a solution to this
> dilemma? I want to try to get the box up to latest and greatest
> standards... and this is frustrating as can be.
Have you tried asking this question on the rpm mailing list?
There are a large number of people there, including many of
the developers, who may be able to answer your questions.
Incidently, rather than a reinstall, you might try doing an
update from the cd. Don't remember all the details of how;
check the man pages or Maximum RPM - which is out of date
except for build purposes.
It would be interesting to discover how this got hosed; the
problem you're reporting of appending a leading / to the
front of all names sounds as if you've either got some
non-standard rpm packages or possibly a misconfigured rpmrc
file.
If you haven't already done so, subscribe to
<rpm-list-request@redhat.co m> and describe your situation
in detail there. Jeff Johnson, who's the current primary
developer, is an ever-active member of the list.
===
Subject: RE: RPMs - Frustration sets in.
From: Ward William E PHDN <wardwe@nswcphdn.navy.mil>
Date: Wed, 1 Mar 2000 13:42:18 -0500
Ah, yes.....
[root@Linus /root]# rpm --rebuilddb
failed to open //var/lib/rpm/packages.rpm
[root@Linus /root]#
First thing I tried when I started having the problems, and
the symptom I was trying to describe to folks.
However, based on the first truly helpful comments on it,
I was able to locate the following entry in
/usr/lib/rpm/macros:
# ---- filesystem macros.
#
%_usr /usr
%_usrsrc %{_usr}/src
%_var /var
I edited the last line (temporarily!) to read
%_var var
And that DID fix the problem with //var, though heaven knows
what other problems will now crop up because something else
is wrong...
Unfortunately, now I'm getting a new error (which is popping
up both ways, with /var and //var)
error creating directory /var/lib/rpmrebuilddb.6398: No space left on device
Ok, now THAT's patently ridiculous.
[root@Linus /root]# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda1 2289010 1070441 1100232 49% /
[root@Linus /root]#
I have a single partition on this machine (I've gotten more
sophisticated since the original build, but this was an
upgrade of a 5.2 machine). I can do a
[root@Linus /root]# touch /var/lib/rpmrebuilddb.6398
[root@Linus /root]# ls /var/lib/rpmrebuilddb.6398
/var/lib/rpmrebuilddb.6398
[root@Linus /root]#
so I know that there is nothing wrong in the directory, either.
I >REALLY< don't want to have to slick this system...
I won't lose much except time, but it's a pride
thing... anything goes wrong in Windows, the only
alternative is to reinstall fresh. I've told a LOT of folks
that's not true in Unix... and pushed them towards Linux.
Now I'm finding myself stymied on this, and on the verge of
slicking it and starting over... Like I said in the title
to the original message, "Frustration sets in".
===
Subject: RE: RPMs - Frustration sets in.
From: "Steven W. Orr" <steveo@world.std.com>
Date: Wed, 1 Mar 2000 15:02:24 -0500 (EST)
People people people. I don't have a quick answer to this
man's problem, but I do want to point out this one
particular inaccuracy.
On Thu, 2 Mar 2000, Juha Saarinen wrote:
=>%-> I disagree. Using ./configure and make on a source distribution
=>%-> discovers many more errors that RPM can simply miss or gloss over. Each
=>%-> to one's own I guess...such is the power of Linux.
=>
=>Configure and make as you mentioned above are for compiling source code into
=>binary, and you can do that with RPM too. Normally however, RPM is used to
=>install ready-compiled binaries. Not the same thing.
No! You can 'normally' do it this way. I 'normally' always
download .src.rpm files and *then* build the binary rpms via
rpm -i
rpm -ba
and only *then* do I
rpm -Uvh
I know that the Maximum RPM book is somewhat out of date,
but it is still well worth the read. It's completely
downloadable so you don't even have to pay for it.
===
Subject: Last question on RPM (at least for a while, and from me) PROMISE!
From: Ward William E PHDN <wardwe@nswcphdn.navy.mil>
Date: Thu, 2 Mar 2000 13:32:45 -0500
Ok, after help from a few folks, I've managed to rebuild a
functioning RPM database on Linus, correct the error in the
filesystem, and am now able to run rpm --rebuilddb. The
only problem is that I was forced to take the RPM
information from a similarly-but-not-identically configured
machine to give me an RPM "seed", as the database was
defunct after all that.... I used a P166 with a different
video card, but with approximately the same packages
otherwise to the PPro to give me the database. I know that
my X-server, therefore, is different. I also know a few
other things are going to be different. What I need is some
advice as to how to "correct" the database. I know there is
a verify option. Should I use that to tell me where the
differences are? How would I go about verifying every
package that's supposed to be installed? And how do I
correct the accelerated X server problem? Does anyone have
a script that can run that can do an automated verify?
Ok, it's more than one question... but they are all related.
I know that somewhere in the heart of it, I'll have to do an
rpm --verify. But how do I get it to tell me all the
installed packages?
Thanks to everyone who has helped, and thanks for a spirited
discussion on RPMs. I've learned a LOT about them wrestling
with this, and reading what folks have to say.
===
Subject: RE: Last question on RPM (at least for a while, and from me) PROM
From: Mike Owen <Mike.Owen@aptissoftware.com>
Date: Thu, 2 Mar 2000 12:36:46 -0600
> From: Ward William E PHDN [mailto:wardwe@nswcphdn.navy.mil]
> Sent: Thursday, March 02, 2000 12:33 PM
> To: Redhat-List (E-mail)
> Subject: Last question on RPM (at least for a while, and from me)
> PROMISE!
>
>
> Ok, it's more than one question... but they are all related.
> I know that
> somewhere in the heart of it, I'll have to do an rpm
> --verify. But how do I
> get it to tell me all the installed packages?
doing
rpm -qa
will give you a list of installed packages. You could then pipe it to rpm
--verify to verify all of them:
rpm -qa | rpm --verify
===
Subject: Re: Last question on RPM (at least for a while, and from me) PROMISE!
From: Matt Housh <jaeger@morpheus.net>
Date: Thu, 02 Mar 2000 12:47:15 -0600
> rpm -qa | rpm --verify
You could also do 'rpm -va' or 'rpm -a --verify'...
===
Subject: RE: Last question on RPM (at least for a while, and from me) PROM
From: Ward William E PHDN <wardwe@nswcphdn.navy.mil>
Date: Thu, 2 Mar 2000 14:09:28 -0500
This didn't quite work for me, but it did give me what I needed:
rpm -qa | awk '{printf("rpm --verify %s\n",$1)}' > /tmp/list
chmod 777 /tmp/list
/tmp/list > listout
===
Subject: Re: Last question on RPM (at least for a while, and from me) PROM ISE!
From: Philippe Moutarlier <philippe@kscable.com>
Date: Thu, 2 Mar 2000 13:21:15 -0700
Ward William E PHDN <wardwe@nswcphdn.navy.mil> writes:
> This didn't quite work for me, but it did give me what I needed:
>
> rpm -qa | awk '{printf("rpm --verify %s\n",$1)}' > /tmp/list
maybe an xargs would have save you the use of awk
rpm -qa | xargs rpm --verify
===