Re: [gentoo-dev] FHS compliant KDE install and multi-version support
В Вск, 07/09/2008 в 15:34 +0100, Ciaran McCreesh пишет: On Sun, 07 Sep 2008 17:24:55 +0400 Peter Volkov [EMAIL PROTECTED] wrote: In any case as FHS and /usr/kde/version installations should set differently SLOT seems that new portage feature is required... May be portage should allow setting SLOT in dependence on USE flag? So what's the slot when SLOT=foo? ( 1 ) bar? ( 2 )? This syntax is not applying in our situation. Expression in SLOT should return only one value at a time. Something like this SLOT=foo:enabled?disabled SLOT=foo:fooenabled?bar:barenabled?bardisabled And should you be able to have the same KDE version with both USE=multislot and USE=-multislot installed at the same time? There are different SLOTs for different USE flags combination and package manager should allow installation same package in different SLOTs. But may be it's useful give developer possibility to disable that ( SLOT=foo::enabled?disabled ). Ah, and this is bug 174407. Or new property for PROPERTIES called multislot which will workaround the problem with invariancy of the SLOT? Uh, how would that work? For ebuilds with such property (may be better name dynamicslot or dynslot) PM should source package with use flags set to get SLOT. Of course it's possible to cache results, sourcing package with all different USE flags combinations during cache generation. -- Peter.
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
On Mon, 08 Sep 2008 11:48:03 +0400 Peter Volkov [EMAIL PROTECTED] wrote: And should you be able to have the same KDE version with both USE=multislot and USE=-multislot installed at the same time? There are different SLOTs for different USE flags combination and package manager should allow installation same package in different SLOTs. That'd require fairly hefty vdb changes. Which, whilst a good thing, makes it very definitely a long term feature. Or new property for PROPERTIES called multislot which will workaround the problem with invariancy of the SLOT? Uh, how would that work? For ebuilds with such property (may be better name dynamicslot or dynslot) PM should source package with use flags set to get SLOT. Of course it's possible to cache results, sourcing package with all different USE flags combinations during cache generation. a) PROPERTIES can't be used to implement any mandatory feature, and b) multiply half a second to however many packages there are using this feature and add that to the resolution time. The metadata cache is necessary. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: a) PROPERTIES can't be used to implement any mandatory feature This is true in the absence of an EAPI bump. However, for completeness, I'd like to mention that it is possible to specify that a given PROPERTIES value have mandatory support in a new EAPI. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjFUMoACgkQ/ejvha5XGaOe3QCeMpfjBytS4QRGLVxb/DDQ2B6O ynkAnAjNiIQmK6I3LPQUQ4HwMGR4HRMy =+P7L -END PGP SIGNATURE-
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
Sunday, 7. September 2008, Olivier Crête Ви написали: The only proper way to do it is to stop the /usr/kde madness for everyone and just install everything in /usr like everyone else does, I am afraid, that would be quite unacceptable for many of us. So I'd suggest another proper way of doing this - just keep it as it is :). George
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
080907 Jorge Manuel B. S. Vicetto wrote: ignoring FHS ... are not valid solutions to this problem. Why ? Who is demanding FHS compliance for what reasons ? Gentoo is not like other distros sometimes needs to find its own way. Given the well-known problems with KDE 4.0 (still) 4.1 , I'ld like to be able to have the option of multiple versions available. I really do appreciate the hard volunteer work the KDE team donates have nothing but thanks to them all, but shouldn't your priority be to get KDE 4.1 into 'testing', so that users can actually try it out ? There's also 3.5.10 , which has been released, but isn't in Gentoo yet. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
Philip Webb wrote: I really do appreciate the hard volunteer work the KDE team donates have nothing but thanks to them all, but shouldn't your priority be to get KDE 4.1 into 'testing', so that users can actually try it out ? There's also 3.5.10 , which has been released, but isn't in Gentoo yet. In fairness, their priority is whatever they *want* to do. No one has the right to dictate what they should and should not be doing -- except themselves. Maybe figuring out the install path is a precursor to all that? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
В Вск, 07/09/2008 в 02:05 +, Jorge Manuel B. S. Vicetto пишет: Our first attempt was to use a multislot use flag[1]. According to that flag, we would set the SLOT and the PREFIX for the install. That has the a very important problem - it breaks the invariancy of the SLOT and as thus been put aside. Could you explain in a little bit more details why it's bad? How portage workarounds this now for binutils? In any case as FHS and /usr/kde/version installations should set differently SLOT seems that new portage feature is required... May be portage should allow setting SLOT in dependence on USE flag? Or new property for PROPERTIES called multislot which will workaround the problem with invariancy of the SLOT? -- Peter.
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
Josh Saddler wrote: In fairness, their priority is whatever they *want* to do. No one has the right to dictate what they should and should not be doing -- except themselves. Maybe figuring out the install path is a precursor to all that? Couldn't agree more that (within reason) the ebuild team really ought to be making the decisions since they have to implement it. As far as the benefits of FHS-compliance goes - I for one would love to not have to reference paths to kde files that change every time a new version comes out. Then again, that could potentially be solved with symlinks as is commonly done with /usr/src/linux.
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
Olivier Crête wrote: On Sun, 2008-09-07 at 02:05 +, Jorge Manuel B. S. Vicetto wrote: I've been thinking on a different method. With this method [3], we would keep using the major.minor slots (4.1, 4.2, etc) so we also wouldn't break the invariancy. We would allow users to select whether to have an FHS compliant install or not (the way to allow that still needs to be discussed) and we would set the prefix based on that. In case the user wants an FHS compliant install, the eclasses would block all kde packages on other slots - except 3.5 (uses other eclasses) and the live versions (for the above reason that it will always be installed under /usr/kde/live-version). The big problem with that idea is that upgrading from one version to another will be very painful as portage will yell with a million blockers. The only proper way to do it is to stop the /usr/kde madness for everyone and just install everything in /usr like everyone else does, if upstream wanted it to be parallel installable, they would have made it that way (like gnome 1.x vs gnome 2.x). I agree that this blocker idea is a non-starter. Personally I don't see what is wrong with the idea of having ebuilds in an overlay using the 4.2 slot when it is time, developers/interested users test the ebuilds there, they can be in their own slot and when the release is made that are moved to slot 4 and put in the tree. There is nothing stopping us from having multiple slotted versions in overlays for testing purposes. We can only have one FHS compliant install. This means users do not build up multiple minor versions of KDE over the years, possibly not realising and not removing them. It also means third party KDE applications can be installed in /usr (as they always have been) and will simply relink to the latest version of kdelibs after an upgrade, rather than requiring a rebuild if you want them to use the latest kdelibs. I do not think we are removing that many options and I think for most users have one slot for KDE 4 would be most useful, I myself would rather use it that way. I am sure it would be possible to multiply slot Gnome minor versions too if the team really wanted to, I don't honestly think it is necessary for most people. For those that need it we can have slotted ebuilds in an overlays that could still coexist with the ebuilds in the tree. To offer ultimate flexibility being able to change the slot would be nice, but honestly I think having some ebuilds in an overlay with a different slot would be fine. Another point is that currently everything is still slotted, 4.0, 4.1 and scm versions. It is only when 4.2 is released that we will have an actual version that cannot be slotted if we stay with this scheme, which I think we should. Thanks, Marcus
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
On Sun, 07 Sep 2008 17:24:55 +0400 Peter Volkov [EMAIL PROTECTED] wrote: В Вск, 07/09/2008 в 02:05 +, Jorge Manuel B. S. Vicetto пишет: Our first attempt was to use a multislot use flag[1]. According to that flag, we would set the SLOT and the PREFIX for the install. That has the a very important problem - it breaks the invariancy of the SLOT and as thus been put aside. Could you explain in a little bit more details why it's bad? How portage workarounds this now for binutils? Portage uses the metadata cached slot when doing dep resolution, so it goes spectacularly wrong. In any case as FHS and /usr/kde/version installations should set differently SLOT seems that new portage feature is required... May be portage should allow setting SLOT in dependence on USE flag? So what's the slot when SLOT=foo? ( 1 ) bar? ( 2 )? And should you be able to have the same KDE version with both USE=multislot and USE=-multislot installed at the same time? Unfortunately, the issue's not as simple as allowing conditionals in SLOT in a future EAPI. Or new property for PROPERTIES called multislot which will workaround the problem with invariancy of the SLOT? Uh, how would that work? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
Philip Webb wrote: 080907 Jorge Manuel B. S. Vicetto wrote: ignoring FHS ... are not valid solutions to this problem. Why ? Who is demanding FHS compliance for what reasons ? Gentoo is not like other distros sometimes needs to find its own way. Given the well-known problems with KDE 4.0 (still) 4.1 , I'ld like to be able to have the option of multiple versions available. I really do appreciate the hard volunteer work the KDE team donates have nothing but thanks to them all, but shouldn't your priority be to get KDE 4.1 into 'testing', so that users can actually try it out ? There's also 3.5.10 , which has been released, but isn't in Gentoo yet. As a lowly user, I would like to keep KDE 3.5.* for quite a while and will most likely not switch until at least 4.3 or better is out. Even that mostly depends on how many issues are still left out there. I realize that I'm not behind the scenes doing the work to keep both maintained but they are going to both be maintained anyway and leaving it like it is has worked fine so far. Unless there is some requirement upstream, I would prefer it be like it is so that we can still choose. I will most likely maintain both KDE 3 and KDE 4 until things get sorted out and I make sure everything works. Nothing worse than upgrading, realizing that the new version isn't ready for my needs yet and having to recompile KDE all over again. Having both would be really nice. My $0.02 worth. Dale :-)
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
Dale wrote: Philip Webb wrote: 080907 Jorge Manuel B. S. Vicetto wrote: ignoring FHS ... are not valid solutions to this problem. Why ? Who is demanding FHS compliance for what reasons ? Gentoo is not like other distros sometimes needs to find its own way. Given the well-known problems with KDE 4.0 (still) 4.1 , I'ld like to be able to have the option of multiple versions available. I really do appreciate the hard volunteer work the KDE team donates have nothing but thanks to them all, but shouldn't your priority be to get KDE 4.1 into 'testing', so that users can actually try it out ? There's also 3.5.10 , which has been released, but isn't in Gentoo yet. As a lowly user, I would like to keep KDE 3.5.* for quite a while and will most likely not switch until at least 4.3 or better is out. Even that mostly depends on how many issues are still left out there. The slotting of KDE 3.* and KDE 4.* was never a question - these will always remain slottable. The question is whether we really need to keep slotting of minor KDE versions in the new 4.* line, i.e. KDE 4.1 and 4.2 slotted on the same system. I think the benefits of an FHS compliant, non-slottable (with other KDE 4 minor versions) install is the best thing for our general user base. I also see how we can have slots outside of FHS for developers, power users and the ones who just like to be different ;-) These can be maintained in an overlay and use different slots than the ebuilds in the main tree. It is no real issue to be able to run a slotted KDE 4.2 install alongside an FHS install of KDE 4.* and so FHS installs can be successfully slotted with other kdeprefix installs too. This helps to make the normal KDE install much simpler to maintain with less gradual build up of cruft over the years (multiple older slots the user is no longer using). It also brings us into line with the FHS compliant Qt 4 ebuilds and other desktops such as Gnome. The purpose of these posts was to solicit further feedback before things are pushed to the main tree. Most other distributions install KDE into the main /usr hierarchy, that is the way upstream intends KDE to be installed and I think it will work well for most users. I do think Gentoo is about choice and so having overlays with ebuilds in a different slot seems to be the best solution we can offer given the constraint of slot invariance. Thanks, Marcus
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
Marcus D. Hanwell wrote: Dale wrote: Philip Webb wrote: 080907 Jorge Manuel B. S. Vicetto wrote: ignoring FHS ... are not valid solutions to this problem. Why ? Who is demanding FHS compliance for what reasons ? Gentoo is not like other distros sometimes needs to find its own way. Given the well-known problems with KDE 4.0 (still) 4.1 , I'ld like to be able to have the option of multiple versions available. I really do appreciate the hard volunteer work the KDE team donates have nothing but thanks to them all, but shouldn't your priority be to get KDE 4.1 into 'testing', so that users can actually try it out ? There's also 3.5.10 , which has been released, but isn't in Gentoo yet. As a lowly user, I would like to keep KDE 3.5.* for quite a while and will most likely not switch until at least 4.3 or better is out. Even that mostly depends on how many issues are still left out there. The slotting of KDE 3.* and KDE 4.* was never a question - these will always remain slottable. The question is whether we really need to keep slotting of minor KDE versions in the new 4.* line, i.e. KDE 4.1 and 4.2 slotted on the same system. I think the benefits of an FHS compliant, non-slottable (with other KDE 4 minor versions) install is the best thing for our general user base. I also see how we can have slots outside of FHS for developers, power users and the ones who just like to be different ;-) These can be maintained in an overlay and use different slots than the ebuilds in the main tree. It is no real issue to be able to run a slotted KDE 4.2 install alongside an FHS install of KDE 4.* and so FHS installs can be successfully slotted with other kdeprefix installs too. This helps to make the normal KDE install much simpler to maintain with less gradual build up of cruft over the years (multiple older slots the user is no longer using). It also brings us into line with the FHS compliant Qt 4 ebuilds and other desktops such as Gnome. The purpose of these posts was to solicit further feedback before things are pushed to the main tree. Most other distributions install KDE into the main /usr hierarchy, that is the way upstream intends KDE to be installed and I think it will work well for most users. I do think Gentoo is about choice and so having overlays with ebuilds in a different slot seems to be the best solution we can offer given the constraint of slot invariance. Thanks, Marcus To try to make my point clearer, if I can set a USE flag or some other config so that I can have both KDE 3.* and KDE 4.* installed at the same time and select which one to login into, I'm cool. That option doesn't have to be available forever but long enough for KDE to get some of the kinks worked out. I'm talking maybe 6 months to a year which will vary depending on the speed KDE gets things worked out and fixed?implemented. I'm not hard to please by any means but I do like changes to not be a overnight thing. I'm to old for things to soak in in a rush. Thanks Dale :-)
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
Dale wrote: Marcus D. Hanwell wrote: Dale wrote: Philip Webb wrote: 080907 Jorge Manuel B. S. Vicetto wrote: ignoring FHS ... are not valid solutions to this problem. Why ? Who is demanding FHS compliance for what reasons ? Gentoo is not like other distros sometimes needs to find its own way. Given the well-known problems with KDE 4.0 (still) 4.1 , I'ld like to be able to have the option of multiple versions available. I really do appreciate the hard volunteer work the KDE team donates have nothing but thanks to them all, but shouldn't your priority be to get KDE 4.1 into 'testing', so that users can actually try it out ? There's also 3.5.10 , which has been released, but isn't in Gentoo yet. As a lowly user, I would like to keep KDE 3.5.* for quite a while and will most likely not switch until at least 4.3 or better is out. Even that mostly depends on how many issues are still left out there. The slotting of KDE 3.* and KDE 4.* was never a question - these will always remain slottable. The question is whether we really need to keep slotting of minor KDE versions in the new 4.* line, i.e. KDE 4.1 and 4.2 slotted on the same system. I think the benefits of an FHS compliant, non-slottable (with other KDE 4 minor versions) install is the best thing for our general user base. I also see how we can have slots outside of FHS for developers, power users and the ones who just like to be different ;-) These can be maintained in an overlay and use different slots than the ebuilds in the main tree. It is no real issue to be able to run a slotted KDE 4.2 install alongside an FHS install of KDE 4.* and so FHS installs can be successfully slotted with other kdeprefix installs too. This helps to make the normal KDE install much simpler to maintain with less gradual build up of cruft over the years (multiple older slots the user is no longer using). It also brings us into line with the FHS compliant Qt 4 ebuilds and other desktops such as Gnome. The purpose of these posts was to solicit further feedback before things are pushed to the main tree. Most other distributions install KDE into the main /usr hierarchy, that is the way upstream intends KDE to be installed and I think it will work well for most users. I do think Gentoo is about choice and so having overlays with ebuilds in a different slot seems to be the best solution we can offer given the constraint of slot invariance. To try to make my point clearer, if I can set a USE flag or some other config so that I can have both KDE 3.* and KDE 4.* installed at the same time and select which one to login into, I'm cool. That option doesn't have to be available forever but long enough for KDE to get some of the kinks worked out. I'm talking maybe 6 months to a year which will vary depending on the speed KDE gets things worked out and fixed?implemented. Your point was perfectly clear and I thought I had been clear in that option is present and will continue to be so for as long as KDE 3.5 is in the tree. That could be years, depending mainly upon whether upstream continues to provide security fixes in some form. I'm not hard to please by any means but I do like changes to not be a overnight thing. I'm to old for things to soak in in a rush. Thanks I think we all know that most people will try KDE 4 whilst maintaining their old KDE 3.5 desktop. I only use KDE 3.5 for testing things now but still run quite a few KDE 3 apps in my KDE 4 desktop session. I hope this reply makes it very clear that slotting of KDE 3.5 with with KDE 4 is not something that is going away. You will have at least two options (KDE 3.5 or KDE 4), some people might prefer more (KDE 3.5, KDE 4.0, KDE 4.1, KDE 4.2, KDE 4.3...) but I think that is overkill for most (and probably always was). Thanks, Marcus
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
080907 Marcus D. Hanwell wrote: The slotting of KDE 3.* and KDE 4.* was never a question but whether we really need to keep slotting of minor KDE versions in the new 4.* line, i.e. KDE 4.1 and 4.2 slotted on the same system. Yes, I understood that (smile). It is no real issue to be able to run a slotted KDE 4.2 install alongside an FHS install of KDE 4.* via an overlay. In that case, much of my unease disappears: users should be willing to learn how to use overlays. This helps to make the normal KDE install much simpler to maintain with less gradual build up of cruft over the years, ie multiple older slots the user is no longer using. It also brings us into line with the FHS compliant Qt 4 ebuilds Yes, if there is a genuine improvement in maintainability for the devs, that's a real reason for making the change. In another msg, you said nothing will change till 4.2 ( 0901xx ) by then hopefully KDE 4 will have settled down to normal usability. The purpose of these posts was to solicit further feedback before things are pushed to the main tree. Well, you have mine (grin). -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
Marcus D. Hanwell wrote: Dale wrote: Marcus D. Hanwell wrote: Dale wrote: Philip Webb wrote: 080907 Jorge Manuel B. S. Vicetto wrote: ignoring FHS ... are not valid solutions to this problem. Why ? Who is demanding FHS compliance for what reasons ? Gentoo is not like other distros sometimes needs to find its own way. Given the well-known problems with KDE 4.0 (still) 4.1 , I'ld like to be able to have the option of multiple versions available. I really do appreciate the hard volunteer work the KDE team donates have nothing but thanks to them all, but shouldn't your priority be to get KDE 4.1 into 'testing', so that users can actually try it out ? There's also 3.5.10 , which has been released, but isn't in Gentoo yet. As a lowly user, I would like to keep KDE 3.5.* for quite a while and will most likely not switch until at least 4.3 or better is out. Even that mostly depends on how many issues are still left out there. The slotting of KDE 3.* and KDE 4.* was never a question - these will always remain slottable. The question is whether we really need to keep slotting of minor KDE versions in the new 4.* line, i.e. KDE 4.1 and 4.2 slotted on the same system. I think the benefits of an FHS compliant, non-slottable (with other KDE 4 minor versions) install is the best thing for our general user base. I also see how we can have slots outside of FHS for developers, power users and the ones who just like to be different ;-) These can be maintained in an overlay and use different slots than the ebuilds in the main tree. It is no real issue to be able to run a slotted KDE 4.2 install alongside an FHS install of KDE 4.* and so FHS installs can be successfully slotted with other kdeprefix installs too. This helps to make the normal KDE install much simpler to maintain with less gradual build up of cruft over the years (multiple older slots the user is no longer using). It also brings us into line with the FHS compliant Qt 4 ebuilds and other desktops such as Gnome. The purpose of these posts was to solicit further feedback before things are pushed to the main tree. Most other distributions install KDE into the main /usr hierarchy, that is the way upstream intends KDE to be installed and I think it will work well for most users. I do think Gentoo is about choice and so having overlays with ebuilds in a different slot seems to be the best solution we can offer given the constraint of slot invariance. To try to make my point clearer, if I can set a USE flag or some other config so that I can have both KDE 3.* and KDE 4.* installed at the same time and select which one to login into, I'm cool. That option doesn't have to be available forever but long enough for KDE to get some of the kinks worked out. I'm talking maybe 6 months to a year which will vary depending on the speed KDE gets things worked out and fixed?implemented. Your point was perfectly clear and I thought I had been clear in that option is present and will continue to be so for as long as KDE 3.5 is in the tree. That could be years, depending mainly upon whether upstream continues to provide security fixes in some form. I'm not hard to please by any means but I do like changes to not be a overnight thing. I'm to old for things to soak in in a rush. Thanks I think we all know that most people will try KDE 4 whilst maintaining their old KDE 3.5 desktop. I only use KDE 3.5 for testing things now but still run quite a few KDE 3 apps in my KDE 4 desktop session. I hope this reply makes it very clear that slotting of KDE 3.5 with with KDE 4 is not something that is going away. You will have at least two options (KDE 3.5 or KDE 4), some people might prefer more (KDE 3.5, KDE 4.0, KDE 4.1, KDE 4.2, KDE 4.3...) but I think that is overkill for most (and probably always was). Thanks, Marcus I agree, having slots for 4.1, 4.2, 4.3 etc is a bit much. KDE 3 and KDE 4 are supposed to be very different desktops. The difference between KDE 4.1, 4.2 should only be bug fixes and adding more features/programs. I think I will be a happy camper after your posts. Thanks for shedding some light on this for me, and most likely others. Dale :-) :-)
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
Jorge Manuel B. S. Vicetto wrote: Some members of the KDE team have been talking for some time about having a FHS compliant install (define KDE prefix as /usr instead of /usr/kde/version). What are benefits of such a change? What happens when KDE release a version breaking ABI (like KDE 5)? Right now [1], there's a conflict between some non-kdelibs kde3 libraries (kexiv2, kdcraw) from KDE3 and KDE4, mainly KDE4 applications being linked with KDE3 libraries. I don't expect ABI breakage in 4.x, but what happens after it? Will I be able to use my desktop in the middle of an upgrade from 4.x to 4.(x+1), when only half of the packages are already updated? In case someone is thinking on suggesting it, ignoring FHS or not allowing the install of multiple versions are not valid solutions to this problem. I might have missed something in your mail, but if you put, say, 4.1 and 4.2 libraries straight into /usr/lib, are you completely positive stuff won't break? [1] Now being the 3.5.9 release in Portage tree and 4.1.0 in an overlay Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
Jan Kundrát wrote: Jorge Manuel B. S. Vicetto wrote: Some members of the KDE team have been talking for some time about having a FHS compliant install (define KDE prefix as /usr instead of /usr/kde/version). What are benefits of such a change? What happens when KDE release a version breaking ABI (like KDE 5)? We would have the option of using a kde prefix in order to slot it with KDE 4, other distros have worked hard to actually slot KDE 3 and 4 installed in /usr/ this time around. Ideally we would work with them to achieve a similar outcome. We would certainly still have options if and when this happens, i.e. using an alternate prefix so that they can be slotted or truly slotting the two in /usr. Right now [1], there's a conflict between some non-kdelibs kde3 libraries (kexiv2, kdcraw) from KDE3 and KDE4, mainly KDE4 applications being linked with KDE3 libraries. I don't expect ABI breakage in 4.x, but what happens after it? kexiv2 etc are effectively KDE libraries that have recently moved to be developed in KDE's repository. We were discussing whether they should continue to be bumped in the media-libs category or not. This is a recent move and they are certainly not core libs. I haven't checked yet but I am not sure whether they break API or not. Will I be able to use my desktop in the middle of an upgrade from 4.x to 4.(x+1), when only half of the packages are already updated? The KDE apps should just link to the latest kdelibs, KDE guarantees ABI stability and so this should be an easy process. It is possible this will not always be as smooth as we would like with libkdeedu etc. Can Gnome guarantee that everything will continue to work at all stages of the upgrade too? I am not sure how I can effectively test that and make a promise but from my experience as long as we upgrade the libs first and the apps second everything will work well. In case someone is thinking on suggesting it, ignoring FHS or not allowing the install of multiple versions are not valid solutions to this problem. I might have missed something in your mail, but if you put, say, 4.1 and 4.2 libraries straight into /usr/lib, are you completely positive stuff won't break So long as things are upgraded libraries first, then applications (as specified by the deps) then this should not cause any issues. Although we will continue having KDE 4.2 applications depend on = 4.2.
[gentoo-dev] FHS compliant KDE install and multi-version support
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello.
Some members of the KDE team have been talking for some time about
having a FHS compliant install (define KDE prefix as /usr instead of
/usr/kde/version). The most important consequence of that option is
that it won't be possible to have 2 or more KDE versions installed at
the same time - it's important to note this restriction doesn't affect
kde-3.5 as it uses different eclasses that install it under /usr/kde/3.5
and the live version as everyone on the team seems to agree that it
should always be installed into /usr/kde/live-version.
We've been trying to find a way that will allow users to do an FHS
compliant install if they want it, while at the same time still allowing
those that are not interested in it to keep using the current scheme.
Our first attempt was to use a multislot use flag[1]. According to that
flag, we would set the SLOT and the PREFIX for the install. That has the
a very important problem - it breaks the invariancy of the SLOT and as
thus been put aside.
The next step was to use a kdeprefix use flag[2]. This flag no longer
touches the SLOT that is set to 4 for all kde-4.X versions. It only
determines if the package will be installed under the FHS compliant
location (/usr) or under the old location (/usr/kde/version). This
however means the users will no longer have the option to have more than
one kde-4.X version installed.
I've been thinking on a different method. With this method [3], we would
keep using the major.minor slots (4.1, 4.2, etc) so we also wouldn't
break the invariancy. We would allow users to select whether to have an
FHS compliant install or not (the way to allow that still needs to be
discussed) and we would set the prefix based on that. In case the user
wants an FHS compliant install, the eclasses would block all kde
packages on other slots - except 3.5 (uses other eclasses) and the live
versions (for the above reason that it will always be installed under
/usr/kde/live-version). One way to decide whether to install on an FHS
compliant location would be to add a use flag, but I don't think adding
that flag for 200+ ebuilds makes sense as it doesn't make sense to have
1 version of some packages and possibly 2 or more of other packages.
So, what am I after in this email? After having an internal discussion
and then opening it up to users in #gentoo-kde and a few other people on
#gentoo-portage, it was suggested I sent a mail here to open this
discussion to everyone and to present the case in a more clear manner.
So, can anyone suggest a good way to accomplish what were trying to do?
At least a better solution than the ones I've presented above? I would
also welcome suggestions on how to configure if the user wants an FHS
compliant install or not (I've thought about setting this var on /etc).
In case someone is thinking on suggesting it, ignoring FHS or not
allowing the install of multiple versions are not valid solutions to
this problem.
~ [1] - The commit where it was added was
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=commitdiff;h=e3a8156bd504e4a377d4eedee123252136da821d
It boiled down to the following:
# setting the slot dep
~if [[ ${KDEBASE} == kde-base ]]; then
~case ${PV} in
~3.9*) _kdedir=3.9 ;;
- - 4.0.8*| 4.0.9* | 4.1*) _kdedir=4.1
- - _pv=-${PV}:4.1 ;;
+ 4.0.8*| 4.0.9* | 4.1*)
+ _kdedir=4.1
+ if use multislot; then
+ _pv=-${PV}:4.1
+ else
+ _pv=-${PV}:4
+ fi
+ ;;
# setting the prefix
- - KDEDIR=/usr/kde/${_kdedir}
- - KDEDIRS=/usr:/usr/local:${KDEDIR}
+ # If the multislot USE flag is set use multiple slots for minor
versions
+ if use multislot; then
+ KDEDIR=/usr/kde/${_kdedir}
+ KDEDIRS=/usr:/usr/local:${KDEDIR}
+ else
+ KDEDIR=/usr
+ KDEDIRS=/usr:/usr/local
+ fi
# setting the slot
+ # The svn versions always need their own slot
~if [[ -n ${KDEBASE} ]]; then
~if [[ ${NEED_KDE} = svn ]]; then
~SLOT=kde-svn
~else
- - case ${PV} in
- - 4.0.8* | 4.0.9* | 4.1*) SLOT=4.1 ;;
- - *) SLOT=kde-4 ;;
- - esac
+ # Assign the slot
+ if use multislot; then
+ case ${PV} in
+ 4.0.8* | 4.0.9* | 4.1*)
+ SLOT=4.1 ;;
+
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
On Sun, 2008-09-07 at 02:05 +, Jorge Manuel B. S. Vicetto wrote: I've been thinking on a different method. With this method [3], we would keep using the major.minor slots (4.1, 4.2, etc) so we also wouldn't break the invariancy. We would allow users to select whether to have an FHS compliant install or not (the way to allow that still needs to be discussed) and we would set the prefix based on that. In case the user wants an FHS compliant install, the eclasses would block all kde packages on other slots - except 3.5 (uses other eclasses) and the live versions (for the above reason that it will always be installed under /usr/kde/live-version). The big problem with that idea is that upgrading from one version to another will be very painful as portage will yell with a million blockers. The only proper way to do it is to stop the /usr/kde madness for everyone and just install everything in /usr like everyone else does, if upstream wanted it to be parallel installable, they would have made it that way (like gnome 1.x vs gnome 2.x). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
