Re: Reinstalling Package modules on Madriva 10.2 after removing gtk

From: Robert M. Riches Jr. (rob_at_one.localnet)
Date: 08/31/05 

Date: Wed, 31 Aug 2005 17:44:02 GMT

On 2005-08-31, chris.lyon@spritenote.co.uk <chris.lyon@spritenote.co.uk> wrote:
> The package installer is the gui interfaced tool that handles the
> installing & removal of packages. It installs by default and I now know
> it is dependant on Gtk & probably one or two other things. Now as to
> why gcc has disappeared I don't know . All I know is that it has gone
> as well. After removing gtk using the tool, gcc is no longer present.
> I have done nothing else and feel that a repair should be possible. I
> assume rpm is what sits at the bottom of all this and since I am
> running Mandriva as a GUI environment I am keen to use the GUI tools as
> soon as I can get them running, Unfortunately I do not know what they
> are called or indeed where they are stored on the system because they
> have been the very tools I have used to do this sort of maintenance so
> I have had little cause to run them from the command line. I am really
> in pursuit of an unknown number of rpm files and their locations.

It puzzles me too why a compiler would get lost when
removing a graphics toolkit. I'd be a little suspicious
that issue might be the tip of an iceberg.

Let me see if I can help. There are three layers of things
involved in MandrX package management:

  - The eye-candy GUI thingy for the point-and-click crowd:
    This probably requires gtk, so you can't use this one at
    present.

  - The text-based urpmi command: This does all the
    automatic package dependency resolutioin in text mode.
    This does not require any graphical stuff, so you should
    be able to use this unless the above-mentioned iceberg
    is pretty big.

  - The text-based rpm command: This does simple package
    installation and such, but without automatic dependency
    resolution. You should be able to use this, but it
    would be a pain to have to manually wade through the
    dependencies.

I would suggest trying to use text-based urpmi to reinstall
the packages you have lost. If your urpmi.cfg configuration
file is set up properly, it should work as quickly and
easily as the eye-candy GUI thingy. If the config file is
not right, you might have to edit it with a text editor.

If urpmi fails, you might have to use the text-based rpm
command. This will probably require several attempts to get
your first package or two reinstalled, but it should
eventually work for you. If possible, a large terminal
window and command-line editing are helpful. Here's how to
use it:

  - Find (and/or download) the .rpm for the first package
    you want to (re)install.

  - Do "rpm -Uvh $pkg1.rpm" (with the package file name in
    the obvious place).

  - If it says you need additional packages, then find
    and/or download them.

  - Do "rpm -Uvh $pkg1.rpm $pkg2.rpm $pkg3.rpm ..." (with
    the package file names in the obvious places).

  - If that says you need additional packages, then go back
    to the second-to-previous instruction and repeat.

With a little luck, you will eventually have a successful
(re)installation of the original package you wanted plus
everything it depends on. You could install packages one at
a time, working up the dependency graph, but I find doing
all related installations in one command is easier. If
there are circular dependencies, then you must use the the
single-command approach.

Once you get your package(s) (re)installed, I would suggest
doing an "rpm -qa" and saving the results in a file. That
file will be helpful if you encounter problems like this
again later.

In fact, because I'm paranoid (and because I once had a
problem with many missing terminfo files) I have a complex
routine for package management. I have a shell script that
does an "rpm -qa" into a file, then iterates through the
list of packages doing "rpm -V $pkg" on each one. (Doing
"rpm -Va" loses information about which mismatch comes from
which package.) Each run, the script puts the package list
and the verification reports in two files. I run the script
immediately before _and_ immediately after each package
change or major system management operation. Comparing
different versions of the files lets me verify that nothing
changed that wasn't supposed to change. If something does
go wrong, the files give me a baseline to guide recovery
work.

> I posted this as 'dragged down by the bootstraps' and have reposted
> because I felt the tone probably grated on some people's sensibilites,
> so I will not reiterate the original problem of trying to install
> wxpython onto the machine.(This is probably neither the time or the
> place to mention this but I had this up and running on Windows XP in
> approximately 10 minutes). I am keen to use Linux as I don't believe
> you should keep all your eggs in one basket but perhaps I am being
> optimistic.

One suggestion: Don't mention Microsoft Corp's eXPensive
products in Linux newsgroups. The Linux groups have been
flooded with nasty whining, griping wintrolls, and there is
risk you might be mistaken for a troll and plonked by the
people whose help you need.

> In retrospect I should post this on a Mandriva specific group, but I
> chose this one because it seemed to be both active and relevent and the
> Mandriva name change seems to have led to a certain degree of
> fragmentation.

I would think the MandrX-specific newsgroups would have been
better.

> In reply to Mr Breuer,
> ...

(I'll leave that paragraph alone.)

Robert Riches
spamtrap42@verizon.net
(Yes, that is one of my email addresses.)