Re: [gentoo-dev] Re: Questions about stabilization requests
On L, 2008-09-06 at 00:33 +, Duncan wrote: > Christian Faulhammer <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Fri, 05 Sep > 2008 21:47:59 +0200: > > >> 2) Should I file stabilization requests on software that works mostly > >> as in everything that I use it for normally but I can force it to fail > >> if I feed it some really strange input or contrive a specific set of > >> options that will cause invalid or incorrect output. > > > > Try to sort it out with upstream (original package author). Depends > > on the problem, if an older stable version shows the same behavior it > > should be no show-stopper. > > Also, consider merging with FEATURES=test and the test USE flag if > appropriate as well. Setting test USE flag is never appropriate as far as I know. FEATURES=test enables the USE flag on its own, and it should never be enabled or disabled in a users USE settings in /etc/make.conf or any other place. FEATURES=test is the thing that can be modified for this. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2008-09-07 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2008-09-07 23h59 UTC. Removals: dev-cpp/libwefts2008-09-02 13:28:55 darkside dev-util/bazaar 2008-09-02 13:32:59 darkside app-i18n/kon2 2008-09-02 13:34:39 darkside sys-fs/trustees 2008-09-02 13:38:28 darkside app-portage/herdstat2008-09-04 05:44:25 dev-zero dev-cpp/libherdstat 2008-09-04 05:44:56 dev-zero Additions: dev-tcltk/tktray2008-09-01 04:34:34 tester app-accessibility/espeakup 2008-09-02 04:16:43 williamh sci-physics/pythia 2008-09-02 08:41:08 bicatali dev-python/sympy2008-09-02 09:13:33 grozin dev-python/rope 2008-09-02 21:16:31 pythonhead dev-ml/lwt 2008-09-02 21:36:39 aballier dev-python/ropeide 2008-09-02 22:17:37 pythonhead dev-java/juel 2008-09-03 10:21:44 fordfrog dev-tex/pdftex 2008-09-03 18:48:17 aballier dev-tex/luatex 2008-09-03 18:53:02 aballier games-server/etqw-ded 2008-09-03 21:18:57 nyhm app-admin/emacs-updater 2008-09-04 10:30:05 ulm games-engines/frobtads 2008-09-05 06:39:00 mr_bones_ net-misc/amazonmp3 2008-09-05 13:35:16 lack net-misc/ssh-askpass-fullscreen 2008-09-05 15:12:59 darkside app-i18n/ibus 2008-09-05 23:47:14 matsuu app-i18n/ibus-hangul2008-09-06 00:23:40 matsuu app-mobilephone/openmoko-dfu-util 2008-09-06 00:56:02 vapier app-i18n/ibus-pinyin2008-09-06 03:24:30 matsuu app-i18n/ibus-anthy 2008-09-06 03:27:21 matsuu app-i18n/ibus-chewing 2008-09-06 03:55:07 matsuu app-i18n/ibus-m17n 2008-09-06 04:24:33 matsuu games-fps/etqw-data 2008-09-06 15:38:52 nyhm games-fps/etqw-bin 2008-09-06 15:39:16 nyhm dev-util/kbuild 2008-09-06 19:18:40 jokey net-dialup/dgcmodem 2008-09-07 07:51:03 calchan sci-biology/glimmer 2008-09-07 13:06:53 weaver app-forensics/lynis 2008-09-07 13:10:59 bluebird sci-biology/glimmerhmm 2008-09-07 13:11:13 weaver dev-perl/IO-LockedFile 2008-09-07 13:16:41 tove dev-perl/Authen-Htpasswd2008-09-07 13:33:47 tove sci-physics/lhapdf 2008-09-07 22:10:27 bicatali sci-physics/hepmc 2008-09-07 22:13:50 bicatali -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-cpp/libwefts,removed,darkside,2008-09-02 13:28:55 dev-util/bazaar,removed,darkside,2008-09-02 13:32:59 app-i18n/kon2,removed,darkside,2008-09-02 13:34:39 sys-fs/trustees,removed,darkside,2008-09-02 13:38:28 app-portage/herdstat,removed,dev-zero,2008-09-04 05:44:25 dev-cpp/libherdstat,removed,dev-zero,2008-09-04 05:44:56 Added Packages: dev-tcltk/tktray,added,tester,2008-09-01 04:34:34 app-accessibility/espeakup,added,williamh,2008-09-02 04:16:43 sci-physics/pythia,added,bicatali,2008-09-02 08:41:08 dev-python/sympy,added,grozin,2008-09-02 09:13:33 dev-python/rope,added,pythonhead,2008-09-02 21:16:31 dev-ml/lwt,added,aballier,2008-09-02 21:36:39 dev-python/ropeide,added,pythonhead,2008-09-02 22:17:37 dev-java/juel,added,fordfrog,2008-09-03 10:21:44 dev-tex/pdftex,added,aballier,2008-09-03 18:48:17 dev-tex/luatex,added,aballier,2008-09-03 18:53:02 games-server/etqw-ded,added,nyhm,2008-09-03 21:18:57 app-admin/emacs-updater,added,ulm,2008-09-04 10:30:05 games-engines/frobtads,added,mr_bones_,2008-09-05 06:39:00 net-misc/amazonmp3,added,lack,2008-09-05 13:35:16 net-misc/ssh-askpass-fullscreen,added,darkside,2008-09-05 15:12:59 app-i18n/ibus,added,matsuu,2008-09-05 23:47:14 app-i18n/ibus-hangul,added,matsuu,2008-09-06 00:23:40 app-mobilephone/openmoko-dfu-util,added,vapier,2008-09-06 00:56:02 app-i18n/ibus-pinyin,added,matsuu,2008-09-06 03:24:30 app-i18n/ibus-anthy,added,matsuu,2008-09-06 03:27:21 app-i18n/ibus-chewing,added,matsuu,2008-09-06 03:55:07 app-i18n/ibus-m17n,added,matsuu,2008-09-06 04:24:33 games-fps/etqw-data,added,nyhm,2008-09-06 15:38:52 games-fps/etqw-bin,added,nyhm,2008-09-06 15:39:16 dev-util/kbuild,added,jokey,2008-09-06 19:18:40 net-dialup/dgcmodem,added,calchan,2008-09-07 07:51:03 sci-biology/glimmer,added,weaver,2008-09-07 13:06:53 app-forensics/lynis,added,bluebird,2008-09-07 13:10:59 sci-biology/glimmerhmm,added,weaver,2008-09-07 13:11:1
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/). 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.
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/). 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
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
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.* . 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
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
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] [RFC] Ability to pass arguments to src_configure/src_compile
On Sun, Sep 7, 2008 at 6:50 PM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
> On Sun, 07 Sep 2008 12:46:45 -0400
> "Marcus D. Hanwell" <[EMAIL PROTECTED]> wrote:
>> > The proposal is not designed to replace all cases. It's designed to
>> > replace the common 50%.
>> >
>> I personally agree with several others who have replied to this
>> thread. The reduction in lines of code/characters seems to introduce
>> an uglier syntax which is harder to read with questionable benefits.
>
> Try using it for a few weeks. Once you're used to it it's considerably
> nicer than going through and implementing pointless src_configures all
> over the place...
>
Yes. And here another point should be brought up. This proposal should
be wider and consider similar changes for the most common used
operations on all phases. Implementing it only for
src_{configure,compile} won't feel so useful as implementing similar
variables for most phases.
Regards,
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Sun, 07 Sep 2008 12:46:45 -0400 "Marcus D. Hanwell" <[EMAIL PROTECTED]> wrote: > > The proposal is not designed to replace all cases. It's designed to > > replace the common 50%. > > > I personally agree with several others who have replied to this > thread. The reduction in lines of code/characters seems to introduce > an uglier syntax which is harder to read with questionable benefits. Try using it for a few weeks. Once you're used to it it's considerably nicer than going through and implementing pointless src_configures all over the place... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
Ciaran McCreesh wrote:
On Sun, 7 Sep 2008 17:31:37 +0200 (CEST)
Vaeth <[EMAIL PROTECTED]> wrote:
Santiago M. Mola wrote:
Alec Warner <[EMAIL PROTECTED]> wrote:
Thomas Anderson <[EMAIL PROTECTED]> wrote:
DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS
Essentially, this is the suggestion to replace the flexible shell code
by some static variables. Besides being less intuitive and less
readable (you have to know the meaning of all the variables to
understand it) it also works only for fixed cases, e.g. if it is
only ./configure (and not ./autogen.sh or something else) which has
to be called, and only if it has to be called exactly once in the
main directory For all other cases, either *everything* has to be
done manually, or you have to introduce even more variables to cover
more cases.
The proposal is not designed to replace all cases. It's designed to
replace the common 50%.
I personally agree with several others who have replied to this thread.
The reduction in lines of code/characters seems to introduce an uglier
syntax which is harder to read with questionable benefits.
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
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] [RFC] Ability to pass arguments to src_configure/src_compile
On Sun, 7 Sep 2008 17:31:37 +0200 (CEST)
Vaeth <[EMAIL PROTECTED]> wrote:
> Santiago M. Mola wrote:
> > Alec Warner <[EMAIL PROTECTED]> wrote:
> > > Thomas Anderson <[EMAIL PROTECTED]> wrote:
> > >>DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
> > >>DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS
>
> Essentially, this is the suggestion to replace the flexible shell code
> by some static variables. Besides being less intuitive and less
> readable (you have to know the meaning of all the variables to
> understand it) it also works only for fixed cases, e.g. if it is
> only ./configure (and not ./autogen.sh or something else) which has
> to be called, and only if it has to be called exactly once in the
> main directory For all other cases, either *everything* has to be
> done manually, or you have to introduce even more variables to cover
> more cases.
The proposal is not designed to replace all cases. It's designed to
replace the common 50%.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
Santiago M. Mola wrote:
> Alec Warner <[EMAIL PROTECTED]> wrote:
> > Thomas Anderson <[EMAIL PROTECTED]> wrote:
> >>DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
> >>DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS
Essentially, this is the suggestion to replace the flexible shell code
by some static variables. Besides being less intuitive and less readable
(you have to know the meaning of all the variables to understand it)
it also works only for fixed cases, e.g. if it is only ./configure
(and not ./autogen.sh or something else) which has to be called,
and only if it has to be called exactly once in the main directory
For all other cases, either *everything* has to be done manually,
or you have to introduce even more variables to cover more cases.
Your second example shows no advantage either since you could just
have rewritten it by standard means anyway:
> src_compile() {
> local myconf="
> --sysconfdir=/etc/${PN}
> --without-xgrid
> --enable-pretty-print-stacktrace
> --enable-orterun-prefix-by-default
> --without-slurm"
>
> if use threads; then
> myconf="${myconf}
> --enable-mpi-threads
> --with-progress-threads
> fi
>
> econf ${myconf} \
> $(use_enable !nocxx mpi-cxx) \
> $(use_enable romio io-romio) \
> $(use_enable heterogeneous) \
> $(use_with pbs tm) \
> $(use_enable ipv6) \
> || die "econf failed"
>
> emake || die "emake failed"
> }
With EAPI=2 you would probably do the above in src_configure which means
that you omit the last line anyway. Moreover, if you dislike using a
temporary variable and just want to collect options you could have
written it this way:
src_configure() {
econf --sysconfdir=/etc/"${PN}" \
--without-xgrid ... \
--without-slurm \
$(use threads && echo \
--enable-mpi-threads \
--with-progress-threads) \
$(use_enable !nocxx mpi-cxx) ... \
$(use_enable ipv6) \
|| die "econf failed"
}
This is simply more intuitive and readable than your suggestion,
and moreover, this can also be used if in the "use threads" part
you have other options than --enable-* or --with-* (e.g. some --disable-*
or even more options in which case your suggestion would become a mess
more and more).
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/ 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
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 . 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/). 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
[gentoo-dev] Maintainer needed for dev-util/biew
Hi, As I'm longer using biew in any way and don't really have any interest in maintaining it, I'm looking for someone to take it over. The package has no open bugs and is seldom updated, but could use a version bump. If you are willing to maintain it, feel free to remove me from metadata.xml and put yourself there instead. Best regards. -- Michal JanuszewskiJID: [EMAIL PROTECTED] Gentoo Linux Developerhttp://people.gentoo.org/spock
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
В Вск, 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/ 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
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
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
