New dependency for kdelibs and kdebase: dbusmenu-qt

[Modestas Vainius]

Hello,

On trečiadienis 05 Gegužė 2010 21:25:16 Alexander Neundorf wrote:
> Somehow I feel like the tone of this email could have been even
> friendlier...
> 
> Sorry that "my excessive RPATH handling" is not good enough for Debian.
> 
> > If you think that CMAKE_SKIP_RPATH=ON is an
> > ultimate solution to the problem, you are mistaken.
> 
> Again sorry that I'm too stupid.

Don't put it like that, this was not personal. However, it is also true that 
RPATH changes were typically done by you (according to svn blame) throughout 
KDE (mostly due to your setup as far as I can tell) so this comment ended up 
kind of directed at you.

> > We have a perfectly
> > valid use cases for RPATH/RUNPATH so skipping RPATH completely is not an
> > option esp. if it is suggested to be done blindly. /usr/lib in RPATH is a
> > bug for which Debian packages may get rejected before they even enter the
> > archive.
> > 
> > However, I have already seen the light in the tunnel with such code in
> 
> > akonadi trunk:
> How to put it.
> I wasn't aware that we have currently an issue with debian packaging.
> It would have helped if you would have brought up this issue again on
> kde-buildsystem (or here on k-c-d).

Well, the issue has already been brought up before on kde-buildsystem. Now I 
tried to find a thread about it and maybe that was 
http://lists.kde.org/?l=kde-buildsystem&m=126600193718722&w=2 by Fedora 
packager. I wasn't quite able to discuss that then, later I forgot and when I 
faced that problem later with KDE 4.4, I needed a fast solution which end up 
being patching out CMAKE_INSTALL_RPATH everywhere. This thread just reminded 
me of that problem again and it would be great if there was a long term 
solution.

FWIW, I don't think that this is a problem *only* for debian packaging. It is 
generally not a good idea to set RPATH when library is being installed to a 
standard location on the system because then administrator is not given a 
chance to override this setting. RUNPATH improves things a bit but still, 
/usr/lib R(UN)PATH is not only useless but also harmful. Read more about this 
at http://wiki.debian.org/RpathIssue (btw, referenced two mails before).

> Or, you could even have proposed a patch. Or, you have a svn account,
> committed something to KDE4Macros.cmake.

Well, it is hard for me to do (or test it) since I don't have such setup which 
needs so many RPATHs. I believe that cmake defaults ( no install rpath ) meet 
debian's and majority of distros needs completely.

> The even better way would have been to post an email to the cmake list or
> to the cmake bugtracker to request that these directories
> (CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES) don't get included when using
> INSTALL_RPATH_USE_LINK_PATH.
> So not just KDE, but any cmake-using project automatically would benefit.

I also think that cmake itself could benefit from more smart RPATH handling 
like that. That stuff in akonadi trunk (which I found completely by accident 
btw) is completely acceptable solution and as I said before, if it was 
deployed in the rest of KDE/kdesupport, I would have nothing to complain 
about. I also see how it should work in your setup as well.

Yes, I know that I could do things better. But in my defence, install rpaths 
are not default (there must be reason for it?) in cmake and other projects do 
not seem to enable it so extensively. So it more looks like KDE problem rather 
than cmake problem. Though cmake could be smarter in this case.
 
> > list(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "${LIB_INSTALL_DIR}"
> > _isSystemLibDir)
> > if("${_isSystemLibDir}" STREQUAL "-1")
> > 
> >   set(CMAKE_INSTALL_RPATH "${LIB_INSTALL_DIR}")
> > 
> > endif("${_isSystemLibDir}" STREQUAL "-1")
> > 
> > I really hope that something like this has been implemented in the rest
> > of KDE trunk as well (I have not checked).
> 
> So please do, and if you're not satisfied, please post a patch.

I'm satisfied by this. The quick question was if it had been implemented in 
the rest of KDE trunk / kdesupport trunk as well. That's because I don't 
follow trunk development but probably will only get to it when 4.5 is about go 
out. Your last mail seemed like you somewhat didn't want to ack. that there 
was a problem and offered CMAKE_SKIP_RPATH as a solution.

-- 
Modestas Vainius <modestas at vainius.eu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100506/bfce6e90/attachment.sig>