Reinstalling Package modules on Madriva 10.2 after removing gtk 4649

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.

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.

better.

(I'll leave that paragraph alone.)

Robert Riches (Yes, that is one of my email addresses.)