Java Mailing List Archive

http://www.redhatconfig.com/

Home » Mandriva Cooker »

Re: [Cooker] Cooker update knocked out nvidia driver and nvidias
opengl driver

Colin Guthrie

2008-06-16

Replies: Find Java Web Hosting

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

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

WTF? Do you even think about what you type anymore? If the library was
needed by the software installed at install time it would have been
installed. If you later add a third party bit of software that needs
that library via a third party source and your system doesn't magically
install the dependency (or the package itself doesn't even report it as
a dependency) then this is 100% nothing to do with Mandriva! Did you
even install an RPM supplied by Mozilla? I suspect it was a tarball
which *has no dependency information* built into it!!!! It does however
have a readme which points you at the website which contains a list of
system requirements which state, quite clearly:
"Linux kernel 2.2.14 (with glibc 2.3.2, XFree86-3.3.6, gtk+2.0,
fontconfig/xft and libstdc++5)"

But going to the Mandriva installer and typing in libstdc++5 is clearly
too hard for you I guess....

If you go down this route (of installing third party
supplied/distributed software) on your system you are expected to at
least have half a clue about what you are doing. I'm sorry that you
don't have someone to hold your hand all the time when installing stuff
- perhaps Mandriva can offer this as an add on? Jeez.


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

WTF is this kind of anti-Mandriva flaming all about Steve? You used to
be a vaguely productive member of the cooker community (even if you were
sometimes asking somewhat neebie questions on a development list - I
guess we were all there once!) but the tone in the last few emails has
been nothing short of nasty and accusatory. Myself and many others on
this list do our best to try and help you out when you have problems and
inform you of the logical and well thought out reasoning behind
decisions but this kind of attitude is not conducive to making me want
to reply any more to be honest.


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

Perhaps arguable in a private email but not on a public mailing list.
Please don't do it.

For reference, many mailing lists operate like this and you'll notice
that almost everyone else on this list will remove a whole heap of
unneeded context too:

See this FAQ from another list that sums things up nicely.
http://www.nausicaa.net/miyazaki/mailing-list/newfaq.html#quoting

But if in doubt:
http://www.google.co.uk/search?q=overquoting+mailing+list

In short overquoting devalues archives and makes it harder for people to
follow threads and pick out the useful bits. That said underquoting does
much the same, so the important part is finding the right balance.
However 100% is definitely not the right balance - it depends on context ;)


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

And please explain, using the points myself, Adam and Anssi have already
made, how a bit of software written against one version of a library
*knows* that it is not dependent on a specific version and that it will
*always* work forever more into the future regardless of the lifecycle
of said separately maintained library?

I'll save you the bother: it can't.


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

Are you serious? This doesn't even vaguely compare! If you want to
compare that, look at how the STL has changed in the last x years or
similar.

If you sit back and look at your whole argument here you should realise
how unworkable this suggestion is.

You've basically just said:

There is no need to have library majors as all libraries should be fully
specified at inception, then developed then never altered (you cannot
even add to it!).

Brilliant. Tell you what, why don't you roll out that idea to the
community and let us all know how you get one. If this is adopted,
Mandriva can alter their library packaging policy to suit!



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

I agree, but the fact is that you still need the version information in
there to ensure that packaging is correct!!!!

Say I compile package foo against the library libbar v2.0 which has a
funky widget() API call not included in libbar v1.0.

foo needs libbar v2.0 but say I try to install the foo package on a
system that only has libbar v1.0 installed. All the logical deps are
satisfied so it should work right? *Bang*, undefined symbol widget()....
"Hmmm, that's strange, I have all the dependencies....."



--

+--------------------------+
|    Colin Guthrie     |
+--------------------------+
| cguthrie(at)mandriva.org |
| http://colin.guthr.ie/ |
+--------------------------+
©2008 redhatconfig.com - Jax Systems, LLC, U.S.A.