Colin Guthrie wrote:
> 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 :)
Maybe, maybe not, but what I am seeing with the software seems to
conform to what I consider to be ridiculous Mandriva standards.
>
> There are numerous ways to get the necessary file.... USB stick, CDROM
> drive?
I could, but why should I have to? If this older version is a
requirement why was it not auto selected and locked as part of, in my
case, selecting all software categories at install time?
>
> 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....
The firewall has been setup so that if a user is logged into the right
domain then the user is transparently passed through the firewall to the
internet, if not, as is the case with my Mandriva Laptop, the firewall
prompts for the right format userid and password, and then does not
accept the Linux response, because it is using a comms protocol that
Linux does not handle properly. The support guys are saying they may
have to change the protocol so that the Corporate Linux Servers will
work with the firewall, but even then there is no guarantee that
Mandriva will work with it.
>
> 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
Sorry Col, but I am following mail etiquette. In Australia it is bad
etiquette to not quote the entire mail history, as well as it being a
mail requirement to top quote responses, especially if the recipient is
required to read the response.
>
>
>> 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.
Yes, but what the linker should be being asked to load, where the
software is not version dependent, is the .so file not the .so.x file.
This way the software will always be guaranteed of loading the latest
version of the shared library, whatever that version happens to be on
any users individual machine.
>
>
>> 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!!
This is exactly what is nothing unusual with Sun's java apis. If they
can do this, so can everyone else.
>
>
>> 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.
It is sensible to increase the major when you are introducing new apis,
i.e. new functionality. Doing this should not cause software that is
using other unchanged apis within the library to fail.

regards,
Steve

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