| Summary: | [QA] dev-util/kdesvn-1.0.4 collides with kde-base/kdesdk-kioslaves-3.5.10 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sandro Bonazzola <sandro.bonazzola> |
| Component: | [OLD] KDE | Assignee: | George Shapovalov (RETIRED) <george> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | esigra, euan, holler.loudly, kde, lifeissecret, telefrancisco |
| Priority: | High | ||
| Version: | 2008.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 243918 | ||
| Bug Blocks: | 239356, 245954 | ||
|
Description
Sandro Bonazzola
2008-10-23 17:20:42 UTC
Hi Sandro. Thanks for reporting this! And sorry for missing it in the first place, I realized I did not have kdesdk-kioslaves installed. Unfortunately this is not a trivial collision, as the files both packages want to install are not identical. Therefore I would like some advice by from kde team on how to proceed about this, so I am adding them to CC. In fact, the change kdesvn wants is rather simple. In principle it boils down to: -exec=kio_svn +exec=kio_ksvn in all the .protocol files (which are themselves identical, except for package name in one of the strings). I'll post the detailed diffs in a short while, its just right now I am in the middle of rebuilding some of the system (screwed up trying to downgrade xorg, sorry about the delay). KDE team: Meanwhile I would like to discuss/get this under your advisement on how to proceed in this situation? I see 2 ways: 1. Ignore (by deleting) these files in kdesvn. Simplest, but not optimal; probably not what users want either. 2. Somehow modify the files when either kdesvn or kioslaves get installed/uninstalled. The most troublesome, but the most desired I would imagine. However this might require splitting these files off into a separate package and providing some eclass func dealing with them. ..Unless there is a standard way to deal with it, of which I would very much like to hear (if there is). George: Hi, I would say most effecient would be 1) just forcing usage of kio_ksvn and using kde bundled stuff that is patching for the source code 2) moving this services under different names... That also need patching in source. And in the end give result to upstream and make them use this, Iirc we have this isue even in 1.2.1 and 9999 ebuild for kde4. When this get fixed you can bump the kde4 stable one too ;] Sorry, I am not totally sure what you suggest: should kdesvn be made to use and accept kio_svn or should kioslaves be changed to accept kio_ksvn? As I understand it, the first one makes more sence, as kioslaves is a standard package, so its better not to mess with it :). I'll look into what's involved into modifying kdesvn then.. As for the 2 (moving services under different name), I am afraid I do not understand. Is there some primer on the relevant kde internals? Can you please elaborate a bit? Actualy i am big fan of the first option. Make kdesvn use kio_svn. The second i porposed only that it is maybe posible, but i have no idea how to do it. Btw since tampakrap is working on this in kde-crazy, you might want to talk to him in #gentoo-kde :] Well, I think I'll just look at that option 1, since it makes the most sense. However now I have a problem. I cannot compile kdesvn nor some of the other packages in kdebase. They complain that I have to install kdelibs first! :), even though I am now inside the running kde and this is after pretty much emerge -e world (up to the relevant point). revdep-rebuild does not find anything bad either. The particulars: Tail of emerging kde-base/kdcop-3.5.10: checking for Qt... libraries /usr/qt/3/lib64, headers /usr/qt/3/include using -mt checking for moc... /usr/qt/3/bin/moc checking for uic... /usr/qt/3/bin/uic checking whether uic supports -L ... yes checking whether uic supports -nounload ... yes checking if Qt needs -ljpeg... no checking for rpath... yes checking for KDE... libraries /usr/kde/3.5/lib64, headers /usr/kde/3.5/include checking if UIC has KDE plugins available... no configure: error: you need to install kdelibs first. relevant part of config.log: configure:31632: checking for KDE configure: 31685: /usr/kde/3.5/include/ksharedptr.h taking that configure: 31715: /usr/kde/3.5/lib64/libkio.la taking that configure: 31733: /usr/kde/3.5/lib64/kde3/plugins/designer/kdewidgets.la taking that configure:31806: result: libraries /usr/kde/3.5/lib64, headers /usr/kde/3.5/include configure:31845: checking if UIC has KDE plugins available configure:31872: /usr/qt/3/bin/uic -L /usr/kde/3.5/lib64/kde3/plugins/designer -nounload -impl actest.h a configure:31875: $? = 0 configure:31889: result: no configure:31900: error: you need to install kdelibs first. Does this remind something? I'd hate to rebuild all of kde related stuff again.. Sorry bad news: http://bugs.gentoo.org/show_bug.cgi?id=243918 I am only kde4/cmake guy, so i have no idea what is this about. Maybe asking cryos would make any difference or someone other from herd who is still on 3.5. (In reply to comment #4) > Actualy i am big fan of the first option. > Make kdesvn use kio_svn. Probably as a temporary workaround that wouldn't prevent users to update their systems this is enough (not enough however to close this bug, as that will require the second solution). Sorry, I thought I committed the fix long time ago, but appears I was just sitting on it :(. Anyway, it is in the tree now, following the suggestion to make kdesvn use svn.protocol. Seemes to be the cleanest and easiest way to handle this situation, as per discussion. The only drawback is that kdesvn now has to depenf on kdesdk-kioslaves, which is a rather small package, so this should be Ok. However, if there are any suggestions on how to handle this better, please do leave comments (and reopen the bug, if this is considered essential). |
