KDE 4.1 Gentoo Ebuilds

Posted by Marcus D. Hanwell on

So there have been quite a few people asking what is happening with KDE 4.1 on Gentoo. There are still no ebuilds in the tree for KDE 4.1 and to be totally honest I have not been actively developing the KDE ebuilds until recently (took quite a long break). It is however something I really feel that we should have and so I have been working with a few other developers and interested users on the new ebuilds in an overlay. I think these ebuilds are almost ready and I am very eager to get them into the tree.

So what have we been doing? We have been working on a set of ebuilds that can be used with portage 2.2, there were a few setbacks when it became clear that EAPI 2 was not likely to be allowed in the tree in the very near term, but good noises are being made on the mailing lists. I think one of the big changes I have been working on is bringing KDE back into the normal file system hierarchy. This means that you will not be able to slot multiple minor versions of KDE such as 4.1 and 4.2 together.

The loss of slotting also means that ebuild maintenance will be significantly easier, externally released packages will automatically relink to the latest kdelibs for example. It also means that users will not build up multiple copies of minor KDE versions such as 4.0, 4.1, 4.2. I think for the majority of our userbase (myself included) this situation is undesirable with few benefits for normal use of KDE. So having one slot for KDE 4 and upgrading in the normal fashion seems to be very beneficial.

This has not been universally accepted as a good thing. I personally think our main tree KDE should always be installed in the normal FHS hierarchy as upstream seems to intend it. I see little benefit for most users, and many developers not closely involved in KDE development, to having multiple minor versions installed. Also having external KDE packages such as k3b and amarok installed in /usr but linking to libraries in a KDE prefix has never been optimal.

My vision is for a default in-tree KDE that installs into the normal FHS tree as Gnome, Qt 4, XOrg etc do. Developers, power users and those that like to tweak would still be free to install slotted versions of KDE in KDE prefixes alongside the FHS KDE. They could also remove the FHS KDE and just use slotted versions too. We discussed during KDE 3.5 bumps how the current slotting was not ideal.

I am certainly open to opinions. It would be good to get wider feedback from the community on which direction they would like to go in and why. This will not affect KDE 3.5 slotting with KDE 4 - they will always be slotted. It will make maintenance of external KDE packages simpler as everything will be in the same tree. Overlays with ebuilds in alternate slots and prefixes are of course still easily possible and people could continue using KDE in this way.

Currently this work is taking place in an overlay. I am quite honestly exhausted discussing why this is or is not a good idea. I hope I have made my position clear and why I think it is a good thing for our user base. I really want to get KDE 4.1 into the tree as soon as possible. I do feel that these changes should be pushed into the tree, defaulting to an FHS compliant install and using a KDE prefix if requested.

What are your thoughts (other than get KDE 4.1 in tree now - we are working on that)?

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

Kevin Bowling on :

Kevin BowlingI agree, I think with the new 6 month release cycle and of course the usual Gentoo stabilization period that there is no reason to slot minor versions for most of us. The kdeprefix system in the current 4.1.1 ebuilds works well and should be left as an option for those in the corner cases, but I just can't see how this is bringing up so many arguments.

Marcus D. Hanwell on :

Marcus D. HanwellI was very surprised. I honestly think that this is the correct direction for the KDE ebuilds to move in for the majority of our user base. I can see case for maintaining flexibility and so added in the kdeprefix use flag. This is Gentoo specific, not used in other distributions and has caused numerous headaches in the past.

I can see reasons to be cautious about the move and I know people are generally resistant to any change. With a six month release cycle the difference between releases is likely going to be reduced and I think only developers/power users trying pre-releases or early releases seriously need the slotting. I posted this to gain wider feedback from the community on what other people think.

Temet on :

TemetThanks for your work :-D
Personally, I will install KDE4 when it will be marked as stable in the tree (I run stable Gentoos).
Do you think this can be achieved for 4.2 ?

Marcus D. Hanwell on :

Marcus D. HanwellIt is difficult to be certain but I would like to see a stable KDE 4 in our tree. If not 4.1 then I feel quite certtain one of the 4.2 releases will be.

atomopawn on :

atomopawnI'm very excited to hear that KDE 4.1 ebuilds may be just around the corner. I will add the kde.git overlay to layman and play around to see what you've got so far!

jkt on :

jktOn Gentoo, Qt4 is NOT installed according to the FHS, but is placed into /usr/$libdir/qt4 instead. That means that there won't be any conflict with Qt5, should it come out someday.

Marcus D. Hanwell on :

Marcus D. HanwellYou are correct on Qt 4 - wasn't my intention to mislead anyone. The rest still stand and even Qt cannot be slotted if they continue to use the binary names of qmake, designer etc. They will have to be slotted in some way.

Hopefully with KDE 5 the KDE community will openly acknowledge the need to install KDE 4 and 5 in the same prefix and provide better support in their build system scripts. If nothing else, users wanting both could install KDE 5 using the kdeprefix flag I added that would install KDE 5 in the /usr/kde/version prefix used in the overlay too.

Kevin Kofler on :

Kevin KoflerActually even KDE 3 and 4 can be made to coexist in the same prefix. The only real issue is with library symlinks: you can't have e.g. libkdecore.so pointing to libkdecore.so.4 and libkdecore.so.5 at the same time... unless, that is, you use different directories to hold the symlinks. That's the solution we implemented in Fedora to allow our kdelibs-devel and kdelibs3-devel packages to coexist: we moved the KDE 4 symlinks to /usr/lib(64)/kde4/devel, while keeping the libraries themselves in /usr/lib(64). There's a small specfile snippet to actually do the moves, and there's this patch: http://cvs.fedoraproject.org/viewvc/rpms/kdelibs/devel/kdelibs-4.1.0-parallel_devel.patch?revision=1.1&view=markup which modifies FindKDE4Internal.cmake to find the symlinks and which also renames kconfig_compiler to kconfig_compiler4 and makekdewidgets to makekdewidgets4 (upstream refused to rename them because they said development stuff can't coexist anyway due to the library symlinks). (The reason we're hacking KDE 4 and not KDE 3 is that CMake keeps these settings in a central place, so we don't have to patch every single app.) Of course you also don't want to throw the headers directly into /usr/include, but /usr/include/kde4 or something like that (but most distributions were already using something similar for KDE 3 - Fedora uses /usr/include/kde for KDE 3 headers), and as data in /usr/share/apps conflicts, we use /usr/share/kde4/apps (as does Mandriva, or did last we checked at least). But that's well-supported by KDE with the appropriate CMake options, the only real source of trouble is library symlinks.

Marcus D. Hanwell on :

Marcus D. HanwellThank you so much for taking the time to fill us in on what Fedora is doing. I knew other distros were doing things like this and remember talking to other distro devs at last year's aKademy. It is great to know the approach you are taking. In our particular case I am not sure all of that is necessary as KDE 3.5 will never be moved.

The layout you are using sounds good and like one we should possibly adopt. How do you deal with conflicting binary names though? Renames or just prevent them being installed at the same time? Also what approach have you taken with the user config directory? I was thinking .kde for KDE 3.5 and .kde4 for KDE 4. Thanks.

Kevin Kofler on :

Kevin KoflerWe don't package conflicting binaries for end user applications, e.g. we only ship one version of Konqueror in a given Fedora release. In Fedora 8, that's 3.5.9 (soon to be 3.5.10), in Fedora 9, it's the KDE 4 version (F9 shipped with 4.0.3, the current update is 4.0.5, 4.1.0 is about to be pushed and 4.1.1 is pending for updates-testing). Of course, where the KDE 4 version wasn't ready, we ship the KDE 3 version instead (usually for the whole module, but we made an exception for kdegames where we have a kdegames package from KDE 4 and a kdegames3 package with the games which haven't been ported - we don't install kdegames3 by default though). This affects kdepim (in F9 only, F10 will have kdepim 4.1.x), kdewebdev (Quanta), kdevelop, kdegames3 and kdeaddons (which no longer exists in that form in KDE 4 and from which we only ship the Atlantik Designer, for use with kdegames3).

As for internal binaries (e.g. kde-config), KDE upstream already prevented conflicts there (by renaming or moving to libexec), except for kconfig_compiler and makekdewidgets as discussed in #4.1.1.

For the configuration directory, we're using .kde for both KDE 3 and 4. It's the only way to ensure settings are automatically migrated on upgrades where possible (of course Plasma won't support all the old Kicker settings), and as, as discussed above, we don't install old and new versions of the same application at the same time, we aren't hit by the issue of application downgrades not being supported by KDE. Doing this while having old and new versions of the same application installed at the same time is not recommended though (because each time you're switching from using the new version to the old one is equivalent to a downgrade), which is why all the major distributions which allow that use a separate .kde4 directory.

K.L. on :

K.L.Personally, I think its a good idea to move everything into FHS. We don't really need slots for every minor version.
But there's another thing: It should be made easier to use KDE3 apps in a KDE4 session and vice versa.
I don't get why there is a need for the .kde symlink. Would it be possible to use the .kde3.5 and .kde4 directories directly?

Marcus D. Hanwell on :

Marcus D. HanwellOne thing I have been working on is using .kde4 as the directory and so allowing .kde to continue being used as the KDE 3.5 configuration directory. It is working well here for me but may need more testing.

Matej Laitl on :

Matej LaitlI agree that FHS compliance is reasonable thing, but still I'd like to have a possibility to for example try in-portage KDE 4.2.x while still having my safe 4.1.y untouched.

There is one solution to this in "testing" branch of kde-testing overlay, proposed by jmbsvicentto: introduce a fhs use-flag while still using SLOTs such as 4.1, 4.2. KDE would either install into /usr and block other versions which would collide on USE = fhs, or install into /usr/kde/${SLOT}/ and allow other versions on USE = -fhs.

In fact the only difference of the two approaches (master and testing branch at the moment) is that the former "blocks" other minor kde versions implicitly by using the same SLOT, and the latter blocks them explicitly in eclass when you have fhs enabled. (thus allowing multiple KDE minor versions installed alongside if you can sacrifice FHS compatibility)

Marcus D. Hanwell on :

Marcus D. HanwellI originally implemented a multislot use flag based upon the one used by gcc that basically did the same thing. The reason I think that this is a terrible idea is because normal users wanting an FHS install will be faced with a block when they simply want to upgrade to the next version. What are their upgrade options at that point?

Unless the package managers can seamlessly upgrade in this situation then you are just making the upgrade process more difficult. Forcing users to remove the old version before upgrading rather than allowing them to upgrade in place.

Matěj Laitl on :

Matěj LaitlWell, portage as of 2.2_rc8 does it. I was surprised but when i wanted to switch from x11-drivers/synaptics to x11-drivers/xf86-input-synaptics, that block each other, portage automagically offered to unmerge older x11-drivers/synaptics. (and done that after installation of xf86-input...)

But I agree that upgrade path with these fine grain SLOTs will be much error error-prone. Hmm, lemme think about it.

Pavel on :

PavelMatej: I believe that most people want to use, not try. Those who want try (a new minor release) may use ~arch.

Slotting adds to ebuild complexity -> slotted ebuilds spend more time with devs and not with users. The sooner a package arrives to users, the sooner it can stabilize because users give feedback via bugreports.

Marcus: I guess the only justification for slotting minor versions is the long compilation time of kde which is a problem when ~arch doesnt work for someone and needs to drop back swiftly to the stable release. If there's really lots of request from the users to have a workaround, wouldnt a kde-base-bin package solve this? (provided that bin packages are easy to maintain)

orzel on :

orzelI don't mind KDE in gentoo being slotted for the major version instead of the minor one. I don't mind installing it according to FHS neither, as far as it's possible to keep the current /usr/kde/* scheme. You seem to say it would still be possible. Can you explain how ? Is it related to the kdeprefix flag ? what does this flag do ?

Justace Clutter on :

Justace ClutterI have been using the kde-experimental overlay for a while now using paludis and am very happy with they way that it is working. KDE SVN updated about every two weeks with no problems.

Jason on :

JasonPersonally, I prefer having things under /usr/kde/version or at least /usr/kde. I wouldn't mind having just kde-3 and kde-4 slots covering all the minor versions.

knue on :

knueI even prefer KDE not slotted except for kde 3 and kde 4. It is was always work for me to uninstall -- let's say -- 3.4.x when I've installed 3.5.x. This got even worse with spilt ebuilds.

Andreas Nilsson on :

Andreas NilssonI actually never noticed that KDE was slotted on minor versions so no loss for me. And I think it is good to adhere to FHS wherever possible.

I would have been nice if you mentioned in witch overlay you are working on this so people can try it out.

I'm currently using KDE4.1.1 from kdesvn-portage overlay and everything works nicely (except nividia drviers, of course).

Platoali on :

PlatoaliI'm comfortable with current system. It is much simpler to find kde related files when all files are in places like /usr/kde than when they are scattered all around the system.

FHS make thing more complicated.

Hynek Fabian on :

Hynek FabianJudging from my kde 3.5.x experiences alone, I would agree with unslotting minor versions. It's mature and stable and there's little reason to have multiple versions. But digging deeper into memory, I can remember several cases of big (for me) bugs in kde 3.1 - 3.4 which made me drop back to previous version (zilion annoances with media:/ kioslave being big example of this).

I don't use kde4 now and don't know real situation (waiting for unmasked ebuilds) so I wont end with conclusion but question:
Are you sure that all changes in kde4 minors are to the better ? That only reasonable fallback is to kde3.5 ?

Karl Zollner on :

Karl ZollnerI just wanted to let you guys no that the ebuilds in the kdesvn overlay worked like a charm. I installed 2 days ago and I can't ever remember a KDE install going so smooth. Good work on those ebuilds guys. Since I do not regularly use KDE (I am a GNOME kind of guy), I have not had the chance to really thoroughly test it, but aesthetically it is pure sugar.

I ran into a few problems with dual monitor usage(I had to reconfigure X for twinview/xinerama instead of two seperate X screens, which I usually use). I set KDE to use Obsidian colors with Oxygen and my GNOME apps use Nodoka midnight- and they fit perfectly together. The few problems I have encountered may be KDE specific, maybe ebuild related- don't know yet, I need to play around with it more and find any problems lurking under that beautiful surface.

At any rate hats off to the guys who wrote these ebuilds-4.1.1 is a treasure to behold, and asiego keeps trying to convince me that KDE has the stuff I am missing in GNOME...I keep trying to convince myself that I am not cheating on GNOME when I fire up KDE, but she is awful damned jealous ;-) .

In my mind any thing more that KDE-3 and KDE-4 slots is absolute overkill, for normal usage.

Wilfred on :

WilfredUsers have been chomping at the bit waiting for kde 4.1 to be in the tree - Neil's kde ebuild tracker http://skrypuch.com/kde4/ has helped a lot though. Of course kde 4.2 will be a much smaller change so going forward I'm not concerned about how long it has taken this time around.

With respect to slotting I think you're right. I can't see there being much demand for 4.0 and 4.1 separate slots, and if it makes the developers' lives easier then there's no question about it.

Volker Armin on :

Volker ArminIMHO being FHS compliant just to be FHS compliant is a bad idea. (FHS in itself is pretty bad...).

I LOVE the fact that kde is slotted - and always was. Installing kde 3.5 and deinstalling 3.4? No biggy. Oh, there is crap left in /usr/kde/3.4 .... it is a great way to find and remove cruft.
In fact, gnome should be slotted and put into /usr/gnome/2.XY too!

At the moment I am emerging kde-4.1.65 from the kdesvn-portage overlay (which seems to work even without portage 2.2) and I love the fact that my 4.1.1 installation is not touched while doing so. No half broken KDE. I can do whatever I want.

And that 'automatically relink' argument is IMHO bogus. If something is linked against kde4.0 it will most likely show problems when it has to work with 4.1 libs. From crashes to no work at all.

So please. Don't do the wrong thing! Let kde stay in /usr/kde/$MAYOR.$MINOR.
From a user point of view it is much more convenient.

Marcus D. Hanwell on :

Marcus D. HanwellDid you read what I wrote? Being FHS compliant is one of several reasons I think that moving KDE to /usr is a good idea, along with the fact that upstream recommends it, other distros do it this way, several maintenance issues we faced when bumping the KDE 3 series.

For you may be it is no biggy needing to remove the last minor version of KDE. For many it is an extra step required with little or no gain. I stated several times that a kdeprefix (or some other) use flag would allow people who wanted to install in the /usr/kde prefix to continue doing so.

What are you basing the automatically relinking argument being bogus on? Do you know the upstream policy on API and ABI? Have you worked with previous releases and had to manage conflicting libraries with different ABIs and multiple dependencies? I work on libraries where we maintain ABI stability, from 4.1 onwards I doubt there will be issues with ABI stability in KDE and if there are then multiple distributions will also need to worry about it.

Hynek Fabian on :

Hynek FabianLinking troubles are not bogus, I've stumbled upon them several times with 3.x. No big deal, I've just reemerged package in question. But problem definitely exist and can bite.

Marcus D. Hanwell on :

Marcus D. HanwellThey certainly exist, as they do with any library. Both KDE and Qt work very hard to maintain ABI stability or bump the .so number/make a new release. Some of those ABI issues were caused by GCC changing the C++ ABI too which was not nice and totally independent of KDE/Qt (but seriously affected both).

Volker Armin on :

Volker Arminbtw, what do you say to this forum post?

http://forums.gentoo.org/viewtopic.php?p=5208394#5208394

to quote:
http://www.pathname.com/fhs/pub/fhs-2.3.html wrote:

Large software packages must not use a direct subdirectory under the /usr hierarchy.

so the FHS even demands /usr/kde (and /usr/gnome)?

Marcus D. Hanwell on :

Marcus D. HanwellQuoting you, "Large software packages must not use a direct subdirectory under the /usr hierarchy." To me that reads that large software packages must not use a direct subdirectory under the /usr hierarchy. They then go on to state, "An exception is made for the X Window System because of considerable precedent and widely-accepted practice." This means that there is an exception to this granted for the X window system although Gentoo no longer installs it that way. Please correct me if I am wrong.

Donnie Berkholz on :

Donnie BerkholzI agree with you on the FHS. But the most important point I have is that the people doing the work should make the final decision, and the people who aren't doing the work can just deal with it.

Marcus D. Hanwell on :

Marcus D. HanwellThanks Donnie. I think we have come to an agreement on the way forward and have just about got a set of ebuilds that offers the flexibility we need. I think it was good to solicit some feedback and let the wider community know what is happening, but I tend to agree with you here. Hopefully we will have some new ebuilds in the main tree very soon.

Daniel on :

DanielFrankly, I've never really liked/understood the whole slotted minor KDE versions thing. I'm happy to hear that this is on the way out.

Alec on :

AlecThanks for the update Marcus!

I think moving it out of the prefix is a great idea. I don't think there's any point of keeping more than one version at the same time.

Keep up the great work!

Volker Armin on :

Volker Armin'no point' really? Like X.Y works great and X.Y+1 has annoying bugs is not a good reason for slots? Soft, painless update?

In fact, besides 'lets bend over for fhs' what are the benefits of de-slotting kde? It only makes updates much more painfull.

Lukasz Ligowski on :

Lukasz LigowskiHow about making binary packages of X.Y before upgrading to X.Y+1?

Hanno on :

HannoAs I still stick with kde 3, what's the status there? (3.5.10 out for a while, not in portage yet)

Marcus D. Hanwell on :

Marcus D. HanwellCarlo said he was working on them. I haven't heard anything from him in the last few days though and so will see if I can find out what is happening with that.

jeffro on :

jeffroSeems like I'm with the majority.

I've got openSUSE 11.0 on my tower - it's too slow and I'm too impatient for Gentoo compile times on that. Anyway, it's got their "official" KDE4 stuff going on. They have three main repositories split like so:

KDE 4.x (current /trunk)
KDE 4.1.x
KDE 4.0.x

Frankly, I think that's ideal. I'd say slot the feature releases but don't bother with the bugfixes.

Gentoo User #31415 on :

Gentoo User #31415I know that sometimes a small minority of complainers can have a louder voice than the majority of people appreciate all the hard work that the devs do. I would just like to say that I really appreciate you guys taking on this truly herculean task of getting the 4.1 ebuilds in shape. You guys rock! :-)

Also, good riddance to the kde prefix in /usr! :-D

China243 on :

China243Just want to say thanks for your efforts and I preffer to keep things as simple as possible, too.

Cogito ergo doleo

[]s
China

Gleepwurp on :

GleepwurpSimpler is Better and makes for a more stable product, anywhere you look. If having kde-4.1 as a "non-slottable" ebuild results in a easier to install and more stable platform, than that's the way we should go.

Thanks alot for your page, its nice to be able to see and hear how 4.1.1 is progressing in Gentoo..

Thanks Markus!

Gleepwurp.

Theuns Cloete on :

Theuns CloeteI noticed that kde-4.1.2 has been added to the portage tree today/yesterday (2008-10-02/03).

Where can one find a good tutorial/HOWTO to emerge it and make sure everything is working 100%

Thanks a lot for the good work. Keep it up!

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA 1CAPTCHA 2CAPTCHA 3CAPTCHA 4CAPTCHA 5


You can use [geshi lang=lang_name [,ln={y|n}]][/geshi] tags to embed source code snippets.