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
