[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kdelibs: breaking the circular dependency

On Friday 20 January 2006 08:52, Steve Langasek wrote:
> Oh, ugh, I was assuming here that it was possible to simply change the
> --exec-prefix used when building, rather than having to add a suffix for
> each binary.  I agree, that doesn't sound fun :)

Ah, right, dumping them under /usr/lib/foo. I knew there was some option I 
was overlooking :)

> > Even if all the filenames in kdelibs5 (for the upcoming KDE 4) are
> > different from those in kdelibs4, given that one could still not
> > install multiple copies of kdelibs-bin, users could only run KDE apps
> > for the version of KDE matching the installed kdelibs-bin.
> Right, so... why should the binaries currently included in kdelibs-bin
> *not* be installed under /usr/lib/kdelibs4 instead of in /usr/bin?  Are
> any of these binaries things that it makes sense for a user to call
> directly?  And if so, perhaps those are the only ones that belong in
> kdelibs-bin, and the rest go in kdelibs4, and with luck the problem goes
> away?

Some programs can be called directly by users, but some of these are also 
generally necessary for KDE apps to run. It's messy.

We could add /usr/lib/kdelibs4 to the path in the "startkde" script, so the 
programs launched from within the full KDE environment would work. But then 
KDE applications launched from GNOME, etc. would still have trouble. I 
don't know how distros like SuSE deal with this, since they put KDE 
in /opt/kde3/{bin,lib,...} or something similar. Presumably they simply 
add /opt/kde3/bin to their basic PATH, but this isn't the sort of solution 
I imagine Debian would want to employ. I couldn't say definitively offhand 
whether an attempt to "hardwire" a path through patching would be 

> If changing the path of these binaries would cause a messy rebuild, then
> perhaps we just make that change for kdelibs5 instead.  Then kdelibs-bin
> could still be merged into kdelibs4c2a, secure in the knowledge that it
> won't conflict with future versions.

Indeed, KDE 4 will provide us with an opportunity to reassess everything. 
Perhaps the move to KDE 4 would be a good point to implement major changes 
(perhaps to cope specifically with multiarch), while simply merging 
kdelibs-bin into kdelibs4c2a for now, in order to smooth the transition to 
KDE 4. But we'll consider to ponder the issue. We have decided that the 
next kdelibs upload (soon...) won't make any major changes.

Thanks again for your input. 

Christopher Martin

Attachment: pgpPo7mCXKWRI.pgp
Description: PGP signature

Reply to: