Originally posted by: walla
I was self compiling a lot of files, like gtp+,glib,orbit,gnome-python, etc. The reason I did this is because I was trying to compile a program that needed new versions of everything. SuSE 9.2, through YaST, did not provide new enough files for this purpose, nor could I find RPMs for them, so I though I'd give it a shot and do it manual. That failed horribly
1) In general, you don't want to dodge your package manager and hand-compile anything apart from trivial programs. Compiling your own stuff is a good way to confuse your system and break things.
2) Double the above advice when it comes to compiling libraries.
3) Triple the above advice when it comes to anything related to GNOME.
If you really must install new library versions, install them to their very own prefix and compile your new program using CFLAGS and/or LDFLAGS that point to that prefix. That way the rest of your system remains blissfully unaware of the new library's existence.
I would like to avoid wiping everything out and starting fresh, because it took me a heckuva long time to set up some of my drivers for the laptop. But if there is no easy way just to roll back to an old version of Gnome, then I guess I have no alternative other than pretending Gnome doesn't exist. I was hoping there was a way to do this through YaST, but I don't want to risk killing KDE as well.
YaST isn't going to help you now, since you bypassed it earlier. If you still have the build directories around, you could do a
make uninstall from each one (or manually hunt through the directories if you already wiped the build dirs). If everything was installed to /usr/local (usually the default for tarballs), that might actually work. But if any of the new libraries overwrote the original ones, you'll have to force RPM to reinstall the originals. And you might need to do this from the console, in case KDE is using any of those new libraries.
If anyone could explain to me, point me to information about what I should have done (as far as properly upgrading GTK, glib, without breaking Gnome)...
As stated above, use separate prefixes for the new libs and set flags so that those are used during the new program's compile. I don't think you'll find any easy distillations of that process online - too much of it depends on the relationship between the libraries and other tools involved and on paths and other system-specific details. Mostly, it's just a matter of picking a PREFIX and using CFLAGS to point there. But with GNOME, there will likely be some complications with tools or components that aren't simply libraries (like the python stuff or scrollkeeper). If you have no idea what any of the above means, then you should start with something a bit more guided (maybe
LFS) before you go blazing your own trail on a system that you actually want to use.
or give me some idea about the structure of Gnome and its components, I would appreciate that as well!
The underpinnings of GNOME are ridiculously complicated. There are dozens of packages involved without even counting any actual applications. You can get a sort-of overview at
the GNOME Dev site, but to really understand much of it you'll need to know C well and be willing to spend a lot of time exploring the code.
Sorry to sound like a wet blanket, but this seems to me like an example of how the system allowing you to do anything you want doesn't necessarily mean that you should.
BTW, what package did you want that caused all these problems? 9.2 is current - I'm surprised that any programs absolutely require newer GTK-related libs to function.
Facebook
Twitter