Steve Morris wrote:
>> 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.

This is hardly Mandriva's fault :)

There are numerous ways to get the necessary file.... USB stick, CDROM
drive?

Also what kind of brandead firewall doens't work for linux clients????
Do you have to do some kind of auth? I've not heard of anything where
linux doesn't work....

Also Steve, just a small pointer on mailing list etiquette, can you
please put a bit of thought into your quoting and strip out the
unnecessary context on your replies? Quoting too much fluff is almost as
annoying as top posting.... well maybe not quite /that/ annoying :p


> 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.

As a develop this is what happens already. The .so file is what tells
the linker what version to use during compilation (or rather linking).
That's why the .so files are shipped only in the -devel packages.

Developers can make be responsibe for such knowledge and ensuring they
have the correct version installed (and can opt to enforce particular
versions in e.g. their configure scripts if they so choose).

For users, this is simply not the case. Users do not want to read docs
and follow this stuff, so the linker will ensure that the "known good"
major is the one the compiled app will use. It's sensible and it means
things wont break.


> 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.

Read that last statement again and you'll realise how impossible that is.

If I write a library I don't release version 1 with full knowledge that
version 42 will not have a specific API function.... I don't explain the
full lifecycle of my library at the beginning so I cannot possibly tell
people using my lib not to call "apis that have been documented as not
necessarily being available in the next version" as I really don't know
that myself!!


> It is just not true that a change in library major guarantees that
> dependent applications will no longer work

Erm? If it will definately work, then why change the major? Just change
the minor and go. This is *exactly* what application majors do. Sure
some apps that only make use of a subset of your library's API should
continue to work, but the simple thing is that it's guaranteed *not* to
work for some people and the flipside is what's actually wrong with
continuing to use the library the developer specifically developed,
tested and used his application with? To me this is fundamentally more
sensible.

Anyway, I've tried my best to correct your view of this and I'm not
going to try any further. You vs. the world + dog is going to be a
lonely quest and cooker is certainly not the place to discuss this.

Col

--

+--------------------------+
|    Colin Guthrie     |
+--------------------------+
| cguthrie(at)mandriva.org |
| http://colin.guthr.ie/ |
+--------------------------+