[kde-freebsd] Prefix decisions redux

[Danny Pansters]

On Friday 15 February 2008 15:18:25 Andy Fawcett wrote:
> On Friday 15 February 2008 15:38:28 Tilman Linneweh wrote:
> > * Michael Nottebrock [2008-02-15 14:08]:
> > > KDE 3.5.9 is going to be released sometime next week and I'm on
> > > standby to prepare the ports for it.
> > >
> > > However, we're still in ports slush until FreeBSD 7.0 goes gold, so
> > > I probably will not be able to commit it straight away. This gives
> > > us an opportunity to move KDE 3 to a different prefix as part of a
> > > regular update. Regrettably, I have not been able to participate in
> > > or even follow up on very well on the KDE 4 porting effort, so I am
> > > asking those who are working on it right now:
> > >
> > > Judging from the experiences gained so far, do you think KDE 4 can
> > > be made to work (with reasonable effort) with KDE3 remaining in
> > > /usr/local?
> >
> > We have spent some effort to make this work, and thanks to David Johnson
> > it kind of works. But debugging the cmake library path ordering problems
> > is definetly not fun.
> >
> > > If the answer is no, possible choices are to just shove everything
> > > into /usr/local/kde3 or to keep the general PREFIX intact but
> > > setting libdir, includedir and perhaps bindir, so libraries,
> > > includes and binaries end up in ${PREFIX}/include/kde3 and so on,
> > > which is supported by KDE 3's buildsystem, but very rarely used and
> > > thus prone to exhibit a few glitches.
> >
> > Previously i didn't like to touch KDE3 just to make the KDE4 integration
> > easier. But with the 3.5.9 upgrade, I agree, we have an opportunity to
> > move KDE3 out of the way, so that we may even put KDE4 into /usr/local.
> >
> > If it is possible i would vote for the (include|lib|bin)/kde3 solution.
> > But /usr/local/kde3 would be ok too.
>
> I think we need to do this, to make life easier in the long run.
>
> The one thing that concerns me is that we do have users who don't start KDE
> from kdm scripts, or even run a KdE desktop at all. Having the binaries in
> a non-standard path (either KDE3 or 4) is going to cause them problems.

Yes. But consider use cases:

The user will be moving from 3 to 4 (assuming he keeps 3 around, and well, he 
has to for many apps for quite a while to come).

Nobody (well... retorically nobody) will do the reverse. So while uber-POLA 
requires IMO that no matter what, kde3 should not break or even introduce 
significant breakage avenue, it's a bit of a different matter what POLA means 
for the kde4+kde3 user. I tend to think that having the kde4 binaries (and 
libs) be looked for first by default stands to reason and would be what the 
user expects.

It's quite easy to copy and slightly modify the startx script (which is just a 
boiler plate script itself, and have that read, say .kinitrc instead 
of .xinitrc. The .kinitrc can then rearrange the path orders and the like. 

And then you tell the user to 'startk' instead of 'startx' or something like 
that.

> If we can have /usr/local/bin for both, and /usr/local/include/kde(3|
> 4) /usr/local/lib/kde(3|4) etc, I think that's probably for the best. I'll
> admit I have no current idea if this will work, but I have a week free to
> help towards any solution.
>
> I'd also do same with Qt3 and 4, while we're at it.

Qt4, if packaged and developed for properly (the latter is the problem), can 
coexist with Qt3. There's no reason to change this default.

>
> Andy

I'd like to add that IMHO the linux situation is not the same as ours. It 
would be more or less the same if most distros would have used /usr as the 
prefix, but with their /opt they already use seperate prefixes (or destdirs 
if you want) for different packages.

Cheers,

Dan