Adam Williamson wrote:
> 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.
>  
I could if the machine in question was connected to the internet or not
sitting behind a firewall known to not work with Linux because Windows
is the corporate standard. When I installed 2008.1 I selected libstdc++6
to be installed not libstdc++5 and there was nothing being installed
that had and issue with that.
> 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...
>  
I am a developer so I fully understand the concept of major and minor
versions, apis and symlinks. Major versions should only be updated when
apis are removed/added, and then this should be notified to the world
via change documentation. As a developer I should be able to depend on
the .so file guaranteeing that I will load the latest version of a
shared library. It is then up to me as a developer, with the appropriate
notification, to determine if the current version of the shared library
I am using, still contains the apis I am using. I should never be forced
to place a dependency on a specific major, unless I am calling apis that
have been documented as not necessarily being available in the next
version, as there is no guarantee that the version will always be there.
It is just not true that a change in library major guarantees that
dependent applications will no longer work, it depends on what is
changed. This is how the ole environment in Windows works and is one of
the few things Microsoft have actually gotten right.

regards,
Steve