[kde-solaris] [kde-discuss] KBE 1.0 - Build enviroment for KDE

[Shawn Walker]

On Dec 11, 2007 11:28 AM, Stefan Teleman <stefan.teleman at sun.com> wrote:
> Shawn Walker wrote:
>
> >> The run-time loader /usr/lib/ld.so.1 binds to $SONAME, not to the
> >> actual filename of the shared library.
> >
> > Whatever. I don't care about the $SONAME, I don't care about any of that.
>
> You should care about $SONAME, -B group and -z nodefaultlib. Because
> if you don't, you sound like you have no clue what you are talking about.
>
> > Again, since you seem to be ignoring my question.
> >
> > Please explain to me plainly how the conflict between two packages
> > that both want to deliver Qt4, both linked against different C++
> > runtimes, and both possibly with the same filename and/or $SONAME is
> > going to be addressed?
>
> What is your question ?
>
> Who is going to deliver two different QT4's in Solaris ? Sun ?

3rd parties; such as this project. Sun, at last check, isn't the one
delivering KDE, Qt4, or stdcxx (yet).

As such, per Sun guidelines on docs.sun.com, they should be installed into /opt.

It should have been obvious what I've been trying to say by now, I've
more than plainly stated it. However, to make it even clearer:

This project is going to be distributing Qt linked against stdcxx; NOT
the standard C++ runtime that every other developer expects for
Solaris.

Therefore, it is logical to conclude that *other* developers that
depend upon a build of Qt that is linked against the *standard C++
runtime* are going to have problems if this project chooses to install
the version of Qt linked against stdcxx into a "default installation
location".

Right now, if a user needed to install both versions of Qt into their
*standard location* and had applications that required both versions
they'd be screwed.

As such, I think this project *must* deliver it's *special* versions
of C++ dependencies into a *non-default location* to prevent conflicts
with C++ dependencies that are built using the *standard C++ runtime*.

What is so difficult to understand about that?

This project should only be using the default installation locations
for Qt, etc. if it is also using the *default* C++ runtime, which it
is not.

> > So instead of pissing of Steve, you'll piss off the admins and ignore
> > the guidelines that your own company established. That sounds like a
> > great idea!
>
<snip>
> My company has already established standards and guidelines for Open
> Source Software, and has already enforced them, by delivering Apache,
> PHP, Perl, Postgres, MySQL5, etc, under /usr.
>
> Have you noticed what's in /usr ? Or is that something you are not
> going to talk about, because it inconveniently conflicts with your
> theories ?

Those guidelines only apply to what *Sun* is delivering. At last
check, Sun's guidelines and documentation on docs.sun.com still
indicate that 3rd parties are supposed to deliver into /opt.

Since this project and *not* Sun is what is delivering these packages,
they fall under 3rd party guidelines.

I also think it's a horrible idea to deliver a version of Qt4 into a
"standard default install location" when it's linked against a
completely different C++ runtime.

I have noticed what is in /usr.

When I say 3rd party, I'm talking about *3rd parties delivering
software* *not* Sun.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben