| View previous topic :: View next topic |
| Author |
Message |
MrFenix
n00b
Joined: 19 Jun 2005
Posts: 25
|
 Posted: Thu Sep 19, 2013 11:08 am Post subject: |
 |
|
| Quote: | | In addition to kdelibs you need to patch some other ebuild, like kdebase-runtime-meta, kde-base-startkde and some other. |
I - like many other people - am not even using those. There are many programs (see my equery) which rely on kdelibs, but can be used without using or even installing the desktop. Some of these programs (like cirkuit) do not have viable alternatives. Use flags are flexible enough to require kdelibs with semantic-desktop for every program which really needs them. If KDE as a whole needs semantic-desktop, kdebase-meta can depend on it. |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Sep 21, 2013 6:11 am Post subject: |
|
|
| creaker wrote: | | In addition to kdelibs you need to patch some other ebuild, like kdebase-runtime-meta, kde-base-startkde and some other. |
Well we can just mask those if need be, though startkde is annoying.
| Quote: | Unfortunately patching ebuilds is not enough for new installation.
Successful kde installation depends on used stage3 rather than portage ebuilds patching.
In particular, some of cmake macros was changes, and now we have additional RDEPENDS checking from cmake. It blocks installing patched ebuilds.
cmake macros contains explicit nepomuk-core, nepomuk-widget, akonadi existance checking. |
cmake files are just text; they're a bit long-winded, but they're not hard to understand. So let's patch them at source.
Do you have any build logs from the failed attempts? |
|
| Back to top |
|
|
creaker
l33t
Joined: 14 Jul 2012
Posts: 651
|
| Posted: Sat Sep 21, 2013 10:00 am Post subject: |
|
|
Hi, steveL!
I have had cmake related problem during last installation. I can't prevent strigi installation by ebuilds patching. Unfortunately I did not save an error message (from cmake).
Maybe my patches is not enough to completely eliminate the strigi. You can see them here: https://forums.gentoo.org/viewtopic-t-970574-highlight-.html |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Sep 21, 2013 6:42 pm Post subject: |
|
|
| creaker wrote: | Hi, steveL!
I have had cmake related problem during last installation. I can't prevent strigi installation by ebuilds patching. Unfortunately I did not save an error message (from cmake).
Maybe my patches is not enough to completely eliminate the strigi. You can see them here: https://forums.gentoo.org/viewtopic-t-970574.html |
Wow, thanks creaker, that's exactly what I've been looking for. We should get the patched ebuilds into kde-lean overlay, so we can try them out and start collaborating. Don't suppose you do IRC do you? I'm in #friendly-coders on freenode (igli.)
Yeah strigi coming in annoyed me too: I noticed kdelibs now has a hard dep on it: it's not patched in your ebuild tho?
| Code: | COMMONDEPEND="
app-crypt/qca:2
>=app-misc/strigi-0.7.7 |
At the time, I was trying to get through an update after 8 months (the post is interesting for update --toolchain) so didn't really want to stop and try patching anything; I just put this in package.use instead (via dialog editor, then added comments and moved them together while it was building), to be sure of things moving forward: | Code: | ## kde-lean
# must have -mysql
dev-qt/qtsql postgres -mysql
kde-base/knode -kontact
# TODO patch kdelibs
app-misc/strigi -clucene -hyperestraier -fam -exif -ffmpeg |
knode has been there for a while ofc, but qtsql took a while to sort out, since it's set in the profile, which USE editing was not taking account of; since the flag was off globally, and the ebuild does not default it to on, it assumed there was no need to set it. So I hacked the logic to always turn off in the file, if portage says it's coming in turned on, and the user has asked to turn it off.
So I have strigi installed now, unfortunately, but it's incapable of doing very much; I'd rather get rid of it altogether, along with Phonon and gstreamer as well. Not sure how the latter would go.
Excellent work with the patches. |
|
| Back to top |
|
|
creaker
l33t
Joined: 14 Jul 2012
Posts: 651
|
| Posted: Sat Sep 21, 2013 8:14 pm Post subject: |
|
|
| steveL wrote: |
Yeah strigi coming in annoyed me too: I noticed kdelibs now has a hard dep on it: it's not patched in your ebuild tho?
| Code: | COMMONDEPEND="
app-crypt/qca:2
>=app-misc/strigi-0.7.7 |
|
Initially I deleted strigi from COMMONDEPEND section. And it worked fine for first two installations. But at last installation I was faced with fact that the checking for strigi presence was built in some other part of system, not in ebuild only. I suspect it was built in cmake configuration macro, or probably in strigi source code. Not sure.
So I've been forced to put strigi back into ebuild in order to prevent conflict between ebuild and cmake configurator.
| Quote: | | So I have strigi installed now, unfortunately, but it's incapable of doing very much; I'd rather get rid of it altogether, along with Phonon and gstreamer as well. Not sure how the latter would go. |
I got strigi installed as well, but it is not started on system boot, so I just did "emerge --unmerge strigi" once kde installation was finished.
In fact I have no a programs that may require strigi (nepomuk e.t.c.) so it may be removed safely. Till now kde works just fine without strigi. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Sep 23, 2013 9:53 pm Post subject: |
|
|
| creaker wrote: | Initially I deleted strigi from COMMONDEPEND section. And it worked fine for first two installations. But at last installation I was faced with fact that the checking for strigi presence was built in some other part of system, not in ebuild only. I suspect it was built in cmake configuration macro, or probably in strigi source code. Not sure.
So I've been forced to put strigi back into ebuild in order to prevent conflict between ebuild and cmake configurator. |
Ah I see, that explains it. It may well be that strigi installs some cmake files that other packages look for, similar to autoconf m4 macros, so we might be able to mock that up. Either way, if it's in cmake we can patch it; ##workingset has people who use it all the time. No stress though, since as you point out your system is fine for now with it unmerged.
| Quote: | | Till now kde works just fine without strigi. |
Well that gives hope that, given the correct patches to make things build, and not fail because strigi is not installed, our desktops will still function correctly; and there's no reason at all that they should not. Apps should be fine with another component not working, and just carry on with the functionality disabled, or they're badly written. And kate for instance is not badly written.
I don't like the idea of just unmerging, in the sense of things not feeling right: I'd foresee portage trying to pull it back in when I upgrade world. Though I guess we could install it for the KDE build, unmerge after and then stick it in package.provided as a workaround hack for the interim.
ATM it's not bothering me, and the other day dolphin actually went off and looked outside the directory where I was which annoyed me til I realised it had found something really useful I'd forgotten about, hehe. So in that sense, I can see the appeal. If it's just used as a file locator when i trigger it, and not running crap in the background then I'm ok with it. I'll see how it goes; atm my machine is nice on 4.10.5-r1. But I will start looking at patching on an automated basis in the next week or two: I'll start with your patches as input data, if that's ok. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
