The Gentoo KDE Team decided not to include KDE 4.5.0 in the main portage tree, due to the lack of the KDEPIM suite, which would cause a lot of trouble to users trying to upgrade. Thus, it will remain in the kde overlay hardmasked. It can be installed with KDEPIM 4.4.5 though, if the user adjusts the keyword files accordingly. The first KDE 4.5.X version that will include the KDEPIM suite will be added to portage as well.
Furthermore, we decided to keep a bit more the live ebuilds of the 4.4 branch, and not to provide any snapshots yet. The Gentoo KDE Guide has been updated to adjust those decisions.
EDIT: Also take a look at comment 10, which has a better explanation
EDIT 2: For news regarding KDE 4.5 in Gentoo, please read http://blog.tampakrap.gr/gentoo-kde-and-qt-september-meetings/
=-=-=-=-=
Powered by Blogilo
August 14th, 2010 at 9:19 pm
Hi
What’s the problem with kdepim? Is kdepim not included in the official 4.5 SC?
August 14th, 2010 at 10:34 pm
Can it not be added to the tree with just KDEPIM hardmasked to only allow 4.4.5 to be installed?
August 15th, 2010 at 7:28 am
baaann is right.
The whole KDE desktop is withheld because of a package. It is not even a dependency package. Please look into this again and prioritize accordingly to the majority’s wishes not to minority’s wishes.
August 15th, 2010 at 8:47 am
Interesting.
@ cael: Correct. kmail is in the middle of a transfer to akonadi, and while it’s sort of ready, the kdepim folks decided not to repeat the mistakes of the not-too-distant kde past and release without KNOWING it’s ready, including proper testing, etc. So they skipped a 4.5.0 full release version, and are scheduled for a 4.5.1 release a month from now. For those willing to test, there is however a release candidate available, that would have been 4.5.0 had they decided to go that way.
Back to 4.5.0. As I said, interesting. I have the overlay in layman and upgraded to 4.5.0 I believe the day after official release, without issue, including no issue with kmail, which is still 4.4.5, which I definitely use. Of course I run ~arch (~amd64 on the main machine, ~x86 on the early atom based netbook), always update deep newuse and do a revdep-rebuild and depclean afterward, plus I’m already running gcc 4.5.1 as well, so everything’s always on latest available ~arch or newer and the system is kept reasonably self-consistent. (I’ve also been running LDFLAGS with –as-needed for quite some time, it’s not a new thing here.) I expect people who have a stable base system, only keywording specific packages, and who aren’t quite as meticulous about keeping a clean system, will experience more problems than I did.
But when I upgraded, 4.5.0 was in the overlay, ~arch naturally, but not hard masked. The only packages in my unmask files are >=portage-2.2_pre and =gcc-4.5*. The only packages in my keywords files are gcc, binutils, lib_users, and pan (live version from my personal overlay), all keyworded **.
Given this blog entry, I guess that means next time I update, 4.5.0 will be hard masked, and I’ll have to add a kde.unmask file with hundreds of entries, to keep from downgrading. =:^( Oh, well… It’s not like I’m not used to such things, running as close to upstream releases as I do.
BTW, based on my experience so far, all the blurbs about 4.5.0 being faster and more stable and bug-free than previous versions are definitely true! In fact, one bug that had been freezing the entire computer (not even the magic-SRQ SUB sequence works, total lockup) after about 24 hours in X, apparently an X/graphics based lockup, that I had attributed to the fact that the freedomware Radeon r7xx (hd4650) graphics drivers I’m running weren’t quite stable yet, has apparently up and disappeared, as I last rebooted on the 10th, and have been in X since I restarted kde after the upgrade (now 48 hours or so, IIRC), with no lockups! It may have been an X/KMS/kernel based graphics bug, but apparently, kde 4.4.x was tickling it, and 4.5.0 doesn’t seem to. =:^)
So I’m a very happy camper ATM, kde-4.5.0 with kmail 4.4.5 and all! I must admit that I’ve been a bit leary about the coming kmail transition to akonadi and I’m not sure it’s going to be painless, but the fact that the kdepim folks /did/ decide to wait that extra month and go with 4.5.1 instead of 4.5.0, is a very good signal, quite wonderfully different from the “release a full version and let the users deal with the fallout of our lack of readiness” that early kde4 was so rightly infamous for. Perhaps kde has learned that lesson. But regardless of what that change with 4.5.1 brings, I’m pretty happy with 4.5.0 and the kdepim 4.4.5 components I’m running right now! This is honestly the first kde4 version I can recommend without reservation! 4.4 was almost there, but 4.5.0 IS there, at least for me! =:^)
August 15th, 2010 at 11:38 am
@Duncan
Good to hear a positive review.
I believe the blog is only referring to KDEPIM being hardmasked, not the entire kde overlay?
@Faisal
Thanks for the support, however it is better that the devs release updates to the portage tree that they are happy they can support, rather than prioritise the majority’s wishes. I just didn’t understand why it could not be updated with the problem app hardmasked
August 15th, 2010 at 2:00 pm
@Duncan
Thanks for your answer! I’ll use the overlay to upgrade to 4.5 (I recently replaced kmail with thunderbird so it shouldn’t be any kdepim problem).
August 15th, 2010 at 3:43 pm
The kde 4.5 decision gets discussed quite heavy on some news pages. There’s an article on the german linux page (pro-linux.de) bashing at gentoo kde team for their decision to not include kde 4.5 in portage. They especially blame the team for their misinformation in this case and asking themselves why gentoo simply don’t use kdepim 4.4.5 in combination with kde 4.5 like other distributions.
This is NOT my opinion! It’s just some information about this case.
August 15th, 2010 at 8:16 pm
First of all, KDEPIM 4.5.0 is not hardmasked, it is not problematic, it simply doesn’t exist. This fact itself arose the issue if we should officially support a release that is not fully complete in our opinion.
KDE 4.5.0 packages are available to overlay, for anyone who wishes to update/test/whatever. We didn’t say we’ll skip the whole 4.5 suite from the tree, we decided to skip only the versions that lack the KDEPIM suite. It’s the KDEPIM guys that wanted to skip their release for now, and we want to bring only fully working versions to tree.
Personally, I support the KDEPIM guys’ decision to skip it for now, since it is not ready, and I don’t find it too important for someone to wait a month to get a fully working KDE.
Finally, I’d like to remind you all that you are able to do the 4.5.0 4.4.5 combination if you just adjust your keywords files. The nature of Gentoo doesn’t allow the developers’ side to do it. We can only point you on how to do it, and in fact I did document it in the installation guide in large detail.
P.S. Of course we’ll be happy to help you for any problem you may have in your upgrade/installation, as usual we can be found in freenode #gentoo-kde, in gentoo-desktop mailing list or in gentoo bugzilla.
August 16th, 2010 at 12:46 am
It’s perfectly fine, tested and supported to use KDE PIM from 4.4.5 together with kdelibs from 4.5.x, many developers are even running that, and it’s how it should be shipped. There’s no reason not to ship other KDE products (such as the Plasma Desktop, or updated apps), it’s a mere release engineering artifact that we didn’t include new PIM packages in the release, KDE’s source and binary compatibility policies are in place to prevent that from happening anyway.
The migration to the Akonadi-based KDE PIM will happen as we deem it stable enough. This, as others point out is to shield users from productivity loss due to issues in Kontact or any of its components. The KDE PIM developers are both actively supporting PIM from 4.4, and in parallel are making the Akonadi-based KDE PIM release-ready.
Now there seems to be the miscommunication that there’s no stable PIM to use right now, and that’s wrong. We recommend shipping 4.4′s PIM with 4.5 as well.
Disclaimer: I work on KDE and have worked with the KDE PIM team on release scheduling.
August 16th, 2010 at 1:55 pm
Lack of kdepim-4.5.0 is NOT the reason why we skipped KDE SC 4.5.0 in Gentoo.
There reason are not addressed regressions we consider significant enugh:
https://bugs.kde.org/show_bug.cgi?id=230247 (minor but annoyance and regression)
or
https://bugs.kde.org/show_bug.cgi?id=245491 (like above)
and
https://bugs.kde.org/show_bug.cgi?id=243991 (this will be fun-breaker for many)
There are also plasma system tray glitches (not addressed yet), plasma folderview bug 247144, dolphin tooltips bug (bug 245491, fixed in 4.5.1), KTar tmpfile regression (fixed in 4.5.1).
Releasing it with known bugs would only cause duplicates on bugs.kde.org. We tend to care for user experience and wait for major regressions to be fixed (there is a question why they’re being introduced in first place).
August 16th, 2010 at 4:19 pm
230247 confuses me, that’s apparently from 4.4.x. If you’re shipping that already, and you don’t want to ship unrelated software because of a bug in something you’re already shipping, that’s … strange.
Anyway, the inital blog was way confusing in that it talked about completely different issues. This kind of communication mishaps can happen.
August 16th, 2010 at 8:11 pm
@sebas
Nothing strange here – kdepimlibs-4.5 requires ~akonadi-1.4 – and even when this bug was introduced earlier – it definitely didn’t happen for me when I was using and testing 4.4 during its lifetime – so from my observation (kdepim packaged Gentoo way – so with dependencies set by myself) it’s actually regression in 4.5, so not a bug in something we’re shipping already.
And we ship kdepimlibs-4.5 with KDE SC 4.5 (to work with kdepim 4.4) because it’s what KDEPIM devs support – your suggestion would be to ship kdepimlibs-4.4? (with previous stable akonadi – from 1.3 series?). This is apparently unsupported – for Plasma workspace akonadi dataengine claims to require KdepimLibs 4.4.60.
August 18th, 2010 at 11:37 pm
Compactor pet…
I found your entry interesting thus I’ve added a Trackback to it on my weblog
…
August 22nd, 2010 at 5:47 am
[...] sabrán, la semana pasada salió la nueva versión establenotanto de KDE 4.5.0. Debido a ciertos problemas con Gentoo, no entrará en Portage (ni siquiera hardmasked), sino que esperarán hasta la 4.5.1, por lo que no [...]
August 22nd, 2010 at 7:23 pm
[...] KDE 4.5.0 in Gentoo [...]
August 31st, 2010 at 5:44 pm
@reavertm Today they released 4.5.1 with several bugfixes
up to their roadmap none of 4.5.x will have kmail/kdepim.
we must wait for 4.6
so i ask, why not adding 4.5.1 too as users are free to use 4.4 kdepim too?
thanks
August 31st, 2010 at 5:49 pm
@Patrizio:
we are going to have a meeting in two days, and we’ll decide about the future of KDE 4.5.1 and the beta kdepim releases
August 31st, 2010 at 5:53 pm
@tampakrap this is good for me as it looks not like a closed door.
Can you please update us when you have any news? (is this blog indexed in gentoo planet?)
thank you all
August 31st, 2010 at 6:08 pm
yes it is, i’ll add the summary of the meeting on a new blog post
September 14th, 2010 at 3:50 am
[...] be released with the Sabayon 5.4 edition? Apparently KDE 4.5.1 is not gonna be labeled stable. Gentoo held off on a 4.5.0 from even going into portage. I’m not sure why as they dumped 4.5.1 to portage and kdepim [...]
November 19th, 2011 at 6:39 am
hello!,I like your writing very much! share we be in contact extra about your post on AOL? I need an expert in this area to solve my problem. May be that is you! Looking forward to see you.
January 15th, 2012 at 4:01 am
Oh, an excellent piece of text! No idea how you were able to say this article..it’d take me long hours. Well worth it though, I’d suspect. Have you considered selling banners on your blog?
January 17th, 2012 at 7:55 am
ool. Your blog looks great, and I’m glad i’ve found something here worth adding to my favorites.
January 31st, 2012 at 12:17 pm
I always was concerned in this topic and still am, appreciate it for posting .