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

[Shawn Walker]

On Dec 9, 2007 4:31 PM, Alan DuBoff <alan.duboff at sun.com> wrote:
> On Fri, 7 Dec 2007, Shawn Walker wrote:
>
> > I understand your argument, but because of the C++ lib mess and all of
> > the special build options we are doing here, I don't think it's
> > viable.
>
> Why?
>
> All binaries should have the runpath compiled into them, and linked with
> the proper libraries.

The runpath is my issue; if the default installation location is one
that could easily conflict or does not make it obvious that
applications built with these are intended only for "our build of
KDE"; then there is a problem.

> > Sun has also established the standard on Solaris 10 systems that
> > well-behaved software lives under /opt and system administrators have
> > come to depend on that.
>
> This was way before 10, but that's besides the point. The software belongs
> in /usr/.

Considering this project has supporting Solaris 10 systems as a focus,
it seems relevant still.

What makes the software "belong in /usr" other than personal opinion?

I've always been of the belief that if you don't like guidelines and
recommendations, you get them changed. You don't throw them "out the
window" when they no longer suit your preferences.

> > Doing otherwise is likely to only infuriate admins; just ask on
> > opensolaris-discuss.
>
> Just, just like other stuff with infuriate them as well. The bottom line
> is that moving forward will cause tension for folks hanging on to the old
> ways.

Some would argue those ways "aren't so old." I only started using
Solaris in 2005; yet I don't think that's "an old way"; and I think it
quite sensible in some regards.

> > Now, as far as Indiana / whatever -- I would concede that installing
> > KDE under /usr, but all the dependences under /opt would be a good
> > compromise.
>
> I believe that Indiana will slowly morph into Solaris. It is only
> scratching the surface with Indiana, but there will be a lot of changes
> coming to Solaris, so get ready for them, IMO.

Sure, I believe the same. But when delivering software to Solaris 10
systems; the "old ways" (if you insist on calling them that) should be
followed until the "guidelines" are changed.

> > That would ensure that our dependencies wouldn't conflict with anyone
> > else's and still allow the expectations of *some* individuals to have
> > KDE in /usr.
>
> I don't understand your point here.

Remember that any C++ dependencies we have are incompatible with other
C++ apps built against the other C++ runtime that comes with Solaris.

The other is because I know what the configuration of our dependencies
are like and how somewhat hacky or builds are since I've been working
with Stefan to get the dependencies going.

That's my point. I think Adriaan has it right.

> > Arguably, we could also have KDE live under /opt for these systems but
> > install a bunch of symlinks into /usr/bin if so desired.
>
> Bzzzt.;-)

*pulls the plug to your buzzer*

> > I personally don't see what the advantage of installing KDE under /usr
> > is if you're going to not have any symlinks in /usr/bin anyway.
>
> Maybe you misunderstand me then, when I say /usr, I mean /usr/bin,
> /usr/sbin, /usr/etc, /usr/lib, etc.../usr being the base.

So how do you want to support side-by-side installations of KDE3&4?
I'm betting on many users wanting to be able to easily switch between
both.

In the end, as much as I dislike it. I can live with kde in /usr and
maybe even our C deps. Though I would still like /usr/local better
since that's what many GNU/Linux apps do today even!

I'm still of the belief that our C++ deps need to go somewhere out of
the way or that makes it very clear they're customised for us.

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