Re: Help! New user having problems compiling GTK, complaining of old GLIB

[resonant evil <air lightz gmail com>]

Hi there

Excellent, informative response.  I definitely did not understand
the layout to that extent, and that definitely puts it into perspective
alot more.. I also never understood why making so many seperate
partitions was usually reccomended when installing, but I had always
just gone with a root / partition and a swap partition..  I guess
I find it difficult to dictate how to split up the filesystem.. This is
only on a laptop with a 60gb drive, and only 30 of it is designated to
Linux, and I wouldn't have a clue how big to allow the various
partitions.

That being said, I guess thats something I'll have to look into a bit
more and I guess I'll go ahead and install a newer version of Debian
(which is what I was assuming you were saying, right?)  Like
Debian-STABLE is quite outdated, and its best to leave a STABLE
installation exactly that; stable..  While I was waiting for a
response I was trying my luck on the FreeNode #debian channel and
generally got the same reccomendation:  To enjoy the latest and
greatest, run -TESTING.  This isn't a die-hard server that I need
to depend on life-and-death and think I would have alot more fun
playing with the new goodies, so I'm gonna go ahead and reinstall
tomorrow.

I really appreciate the informative response and I'll definitely remember it :)
Thanks m8

On 1/9/06, William D. Tallman <wtallman olypen com> wrote:

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 mailing list
gtk-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-list