On Sat, 2008-06-14 at 10:57 +1000, Steve Morris wrote:

> The thing that completely frustrates me about this concept, apart from
> an end user viewpoint of lack of standards, is that I cannot go to the
> mozilla site or sun site and download their products because of not
> installing in 2008.1/cooker because of this version dependency, and this
> version dependency is on libstdc++.so.5 (might have the actual library
> name wrong here but the version is right) whereas the current version in
> Mandriva is .so.6.

You're just...not really getting it.

Okay, first of all:

[root@(protected)

ftp://carroll.cac.psu.edu/pub/linux/distributions/mandrivalinux/devel/cooker/i586/media/main/release/media_info/files.xml.lzma

ftp://carroll.cac.psu.edu/pub/linux/distributions/mandrivalinux/devel/cooker/i586/media/contrib/release/media_info/files.xml.lzma
libstdc++5:/usr/lib/libstdc
++.so.5                              
libstdc++5:/usr/lib/libstdc++.so.5.0.7

Just install libstdc++5 . Problem solved.

Maybe you'll find it easier to understand if you look at it from another
perspective?

Imagine you're a coder. You've written a shared library named
libfoobar . It turns out to be really useful, and there's a ton of
people using it for their apps.

Now it helps to keep in mind what a shared library *does*. I'm not a
coder so I think of it as a little black box that does useful stuff. The
point is this: there are functions that many applications often need to
do. Instead of each app writing its own code to do these things, it
makes sense to have a shared lump of code which does them, and then
whenever you're writing an app which needs to do these things, you just
call the shared library.

So imagine a big black box with a bunch of little holes into which you
can put stuff, and a bunch of buttons on the front. You know that if you
want to do something specific to an object, you can stick it in one of
the holes, press one of the buttons, and it'll come out the back, with
whatever you wanted to do to it...done. That's a shared library.

Okay, so, you've got your awesome shared library called libfoobar . Lots
of people love it. Life is great.

But then you realize that - for some reason or another - you need to
change something about how it works. Let's go back to the big black box:
for whatever reason, you realize you have to change where one of the
holes is, or change its shape, or move one of the buttons, or something.

However, the users of the machines are just dumb robots. They can't
adapt to change. They just roll up, push something at a certain spot,
and poke somewhere they think a button is. What do you do?

You can't just change the box over without letting anyone know.
Everything will break. The robots will roll up, whack whatever they're
carry against the solid wall of the box, poke it somewhere there isn't a
button any more, and there'll be mass confusion and a big pile-up of
confused robots.

So you make a *new* big black box and call it Big Black Box 2. Then you
call all the owners of the robots and tell them they have to reprogram
their robots if they want to use Big Black Box 2.

This is *why we have* library majors. Because library authors, over
time, have to change how their libraries work. And when they do that,
the applications that use those libraries *just won't work anymore*
until they're rewritten. You're sitting there with your libfoobar code,
and you just changed a bit and you *know* that's going to break things
for at least some of the apps that use your library.

It would be completely irresponsible to just bump the version by 0.01
and send it out into the world, with the same filename, for all the
world as if nothing had changed and everything would go on working just
like always. That'd be silly!

This is why we invented library majors in the first place: so you can
send the library out with a new major version. This is the equivalent of
calling your new box Big Black Box 2 and calling all the robot owners.
It *lets people know* that the library has changed. It signifies that
code probably won't *work* with the new version of the library until
it's rewritten. It's a simple and sensible answer to an unavoidable
problem: library interfaces get broken, how are we going to tell people
about it? Answer: library majors. *Not* having them is a far worse
situation than having them.

Sorry for the long post and the probably incoherent metaphor, but you
are clearly just not understanding the concept here, so I'm trying to
present it from a different angle...
--
adamw