On Mon, Jan 09, 2006 at 02:45:13AM -0500, resonant evil wrote:
<snip>
> I am truly a new user trying to learn the ropes, but I have no clue how to
> go about either A> Removing my old GLIB installation or B> Designating it to
> the right installation
>
> I am not even sure which version is installed where :S
>
> If I try and unmark the glib-dev-2.0 or glib-2.0 from synaptic, it's going
> to wipe out a whole ton of applications with it supposedly, so I decided
> against it
>
> The INSTALL file in the GLIB package tells me to to a "rm -fr
> /install-prefix/include/glib.h and rm -fr
> /install-prefix/include/gmodule.h", and upon further searching, it would
> appear the 2 installations on my system are in /usr/include and
> /usr/local/include (well, I'm assuming at least because it found those files
> in both of those locations.) I haven't a clue though which one contains my
> GLIB-2.8.5 instead of the old one that configure is complaining about.
This is not so much a problem about Gtk as it is about Linux itself, so
I'll wade in here.
What you need to know in order to understand the *nix OSes is this:
everything, and I mean everything, is a flat file of some sort. Which
means that there are a few really important concerns that are relevant.
Probably the most important is file permissions, that tell who can do
what with a file, but that's not pertinent here. The second most
important concern about files is where they live.
There is a standard file structure that the *nixen observe and is
roughly common to all of them. So here goes a thumbnail sketch:
There are three tiers of file levels in general: 1) Root; 2) User; 2)
Local. 1), signified by '/' is the top level and it is canonically
limited to system files, files used by the operating system itself. 2),
signified by /usr, is the next tier down and duplicates the relevant
types of system files that also serve the applications that the
operating system enables. 3), signified by /usr/local, is reserved for
all software that is local to the machine in question. For a standalone
or desktop machine, that means something different that it does for
those that are (local) nodes on a network.
How this works out is that root ('/') is usually fairly common to the
operating system in question, here, GNU/Linux. User level ('/usr') is
the level that is populated with the files provided by the distribution
that's installed. Local level ('/user/local') is populated at the
discretion of the owner of the machine, and that's where all the stuff
that the owner acquires and builds is, or should be, located.
The confusion begins when the applications/suites/etc are packaged in
different ways. Distros package their stuff as binaries, providing
source code as required, because that's easiest to install. The problem
is that folk from windows expect that is the only way that software is
available and so go looking for binary packages of non-distribution
stuff, which can very easily wind up duplicating (stomping over the top
of) that provided by the distribution. Packaged binaries almost always
are installed at the /usr level, presenting themselves as legitimate
distro-certified software, but anyone can package a binary of anything,
using the same tools. So what are you getting if it's not from the
distro?
Classically, stuff is compiled from source code using the provided
development software (compiler, automake, etc), and if it works okay,
can then be packaged for rpm, apget or whatever. But if one is
compiling for oneself, why package it? It should automatically go at
the /usr/local level where it does not conflict with what is at the tier
above. There are any number of schemes available for keeping track of
what's on one's system at that level, and a package manager is not only
unnecessary but ultimately confusing.
If this makes sense, then what you need to know is that what is at the
/usr level is, or should be, part of the distro package. Anything at
/usr/local is wholely the responsibility of the user/owner.
You may ask: What's so important about keeping them separate?
The answer is that it's very much non-trivial to configure an entire
installed *nix system, and the people who produce the distributions have
their work cut out for them in the endeavor to put together an
installation package that is configured to be stable enought to use, yet
recent enough to be relevant. The user, especially the newbie, puts
him/her system at peril when he/she starts tinkering around with that
distro level stuff. Which is why upgrading is so much harder than
simply doing a fresh installation of a newer distro version.
I won't go into the details here, but suffice it to say that GNU/Linux
is undergoing, and will probably continue to undergo, a rapid and
extensive rate of development. That means that new versions of
libraries are issued regularly, and backwards compatibility is not
always a top priority. So constant change must be expected, and
accommodated. To make this even worse, it's quite often possible to
have multiple versions of libraries living very happily side by side at
the /usr level, but not always. So the possibility for screwing things
up is commensurate with the possibilities for creating a powerful and
widely applicable system.
Ergo: change stuff at the root and /usr level by changing a distro
version. Which means keeping /usr/local separate. In fact, it's a very
good idea to keep /usr/local on a separate partition from the / install.
All that said, now look at your own system and see if you can pick out
what's going on by looking at what lives where. That which lives at
/usr should be distro packages. Put anything else at /usr/local.
> I would appreciate any help or steps towards fixing this problem very much,
> and I look forward to some help hopefully :( Things like this make Linux
> very discouraging for the new user :(
What's really discouraging is when there is a single remediation for all
problems: Reinstall your operating system! Sound familiar?
Here, there is help almost everywhere you look, if you are appreciative
and receptive. Very different world. But, GNU/Linux is not
Applianceware, and does not function all automagically, which means it
will inevitably become frustrating at times. Think you'll find it's
worth it though.
Good luck,
Bill Tallman
_______________________________________________
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
