Comments
I 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.
#1 Kevin Bowling (Homepage) on 2008-09-07 17:10
I 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.
#1.1 Marcus D. Hanwell on 2008-09-07 18:14
Thanks 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 ?
#2 Temet (Homepage) on 2008-09-07 17:26
It 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.
#2.1 Marcus D. Hanwell on 2008-09-07 18:08
I'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!
#3 atomopawn (Homepage) on 2008-09-07 17:27
On 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.
#4 jkt on 2008-09-07 17:33
You 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.
#4.1 Marcus D. Hanwell on 2008-09-07 17:43
Actually 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.
#4.1.1 Kevin Kofler (Homepage) on 2008-09-07 20:27
Thank 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.
#4.1.1.1 Marcus D. Hanwell on 2008-09-07 20:46
We 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.
#4.1.1.1.1 Kevin Kofler (Homepage) on 2008-09-07 21:09
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?
#5 K.L. on 2008-09-07 17:34
One 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.
#5.1 Marcus D. Hanwell on 2008-09-07 18:10
I 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)
#6 Matej Laitl (Homepage) on 2008-09-07 17:50
I 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.
#6.1 Marcus D. Hanwell on 2008-09-07 18:07
Well, 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.
#6.1.1 Matěj Laitl (Homepage) on 2008-09-07 18:59
Matej: 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)
#6.2 Pavel (Homepage) on 2008-09-07 18:32
I 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 ?
#7 orzel on 2008-09-07 18:35
I 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.
#8 Justace Clutter (Homepage) on 2008-09-07 21:36
Personally, 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.
#9 Jason on 2008-09-07 22:34
I 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.
#10 knue on 2008-09-07 23:15
I 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).
#11 Andreas Nilsson on 2008-09-08 01:00
I'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.
#12 Platoali on 2008-09-08 01:30
Judging 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 ?
#13 Hynek Fabian on 2008-09-08 04:43
I 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.
#14 Karl Zollner (Homepage) on 2008-09-08 06:00
Users 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.
#15 Wilfred on 2008-09-08 09:12
IMHO 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.
#16 Volker Armin on 2008-09-08 09:13
Did 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.
#16.1 Marcus D. Hanwell on 2008-09-08 10:58
Linking 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.
#16.2 Hynek Fabian on 2008-09-08 11:47
They 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).
#16.2.1 Marcus D. Hanwell on 2008-09-08 12:29
btw, 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)?
#17 Volker Armin on 2008-09-08 10:43
Quoting 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.
#17.1 Marcus D. Hanwell on 2008-09-08 10:51
I 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.
#18 Donnie Berkholz (Homepage) on 2008-09-08 11:14
Thanks 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.
#18.1 Marcus D. Hanwell on 2008-09-08 23:35
Frankly, 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.
#19 Daniel (Homepage) on 2008-09-08 13:11
Thanks 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!
#20 Alec on 2008-09-08 15:30
'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.
#21 Volker Armin on 2008-09-08 15:41
How about making binary packages of X.Y before upgrading to X.Y+1?
#21.1 Lukasz Ligowski on 2008-09-09 12:09
As I still stick with kde 3, what's the status there? (3.5.10 out for a while, not in portage yet)
#22 Hanno (Homepage) on 2008-09-08 19:26
Carlo 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.
#22.1 Marcus D. Hanwell on 2008-09-08 23:37
Seems 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.
#23 jeffro on 2008-09-09 17:51
I 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
#24 Gentoo User #31415 on 2008-09-09 18:38
Just want to say thanks for your efforts and I preffer to keep things as simple as possible, too.

Cogito ergo doleo

[]s
China
#25 China243 (Homepage) on 2008-09-14 04:35
Simpler 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.
#26 Gleepwurp on 2008-09-18 18:53
I 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!
#27 Theuns Cloete on 2008-10-03 07:38
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