[gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only
Hello, As some of you may have noticed, lately introduced 'double include preventions' have caused changes in effective phase functions in a few ebuilds. Also, often it is undesirable that change in inherits of an eclass may cause an undesired change of exported functions. To solve these problems, we are proposing the following: 1. If an ebuild does not provide an explicit phase function, the phase functions *directly exported* by *directly inherited* eclasses are used to find a suitable default, 2. Thus, if an eclass inherits another eclass and expects the phase functions of that eclass to be effective to the ebuild, it needs to create its own phase function and export it. This should make the ebuild behavior simpler to understand and saner. It should also fix the forementioned issues, and allow us to make the 'source eclasses only once'[1] proposal simpler. [1]:https://bugs.gentoo.org/show_bug.cgi?id=422533 -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)
On 14.08.2012 00:24, Diego Elio Pettenò wrote: On 13/08/2012 11:29, Alexandre Rostovtsev wrote: /usr/lib/pkgname/ is a directory like /usr/libexec/ or even /bin. It shares absolutely zero things with the arch-specific $libdir ,or lib64/. Yes I know that FHS allows it. I still think it would be cleaner to use /usr/libexec. I highly dislike libexec and have been moving stuff over /usr/lib/$pkg/ on daily basis You (and Kay) want to be right ignoring the fact that $tons of software expects /usr/lib to just be another $libdir. Count me in then I guess :/
Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)
On 14.08.2012 03:24, Olivier Crête wrote: On Mon, 2012-08-13 at 17:56 -0400, Mike Gilbert wrote: On Mon, Aug 13, 2012 at 2:29 PM, Alexandre Rostovtsev tetrom...@gentoo.org wrote: On Mon, 2012-08-13 at 11:14 -0700, Diego Elio Pettenò wrote: Beside the fact that these would probably have looked better in /usr/libexec See Kay Sievers's comment at https://bugs.freedesktop.org/show_bug.cgi?id=51617 : /usr/lib/pkgname/ is a directory like /usr/libexec/ or even /bin. It shares absolutely zero things with the arch-specific $libdir ,or lib64/. /usr/lib/pkgname/ is the canonical application private directory. It has the multi-lib or arch-specific rules as /bin. So... where should GRUB2 be installing its modules? Currently they get installed in /usr/$(get_libdir)/grub/$cpu-$platform, where cpu and platform are determined by use flags. Should we drop the get_libdir and put them in /usr/lib/grub instead? Should I even worry about it? There really have no reason to be in $(get_libdir) as they're not compiled for the platform implied by $(get_libdir) ! +1, that's correct.
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Mon, Aug 13, 2012 at 11:24 PM, Greg KH gre...@gentoo.org wrote: On Thu, Aug 09, 2012 at 03:47:19PM -0400, Rich Freeman wrote: On Thu, Aug 9, 2012 at 3:24 PM, Canek Peláez Valdés can...@gmail.com wrote: I agree with Greg Kroah-Hartman: I actually like (and want) a vertically integrated, tightly coupled way of doing things. Well, if you completely agreed with him you wouldn't be running Gentoo (or Debian, or other general-purpose distros). He advocates that ordinary users should use more purpose-driven distros, where all of this stuff is less of an issue. That is not what I said, or mean at all. Given that I'm a Gentoo developer, and have been for a very long time, I find it very strange that you would think otherwise. I did clarify my post in a reply, linking to your post and of course stating that you could clarify. Your words were: I just don't think it can be done well, sorry, which is why I strongly recommend tightly-coupled distros for desktops for anyone (like Fedora or openSUSE or Ubuntu), and Debian or Gentoo only for servers or embedded systems where you know exactly what you are putting together, and why you are doing it that way. I'm not a big fan of putting words in mouths, so if I misread that than I apologize. In any case, I can't really argue much with that statement as-is, although I'd probably carve out an additional exception for enthusiasts or those who otherwise like to tinker under the hood. If you want strong vertical integration, you probably will never get as much of it with Gentoo as you might get with a tightly-coupled distro. Rich
[gentoo-dev] a libtool + multilib gentoo host + 64-32 cross-prefix problem: a request for eyeballs
I've stumbled onto an interesting little problem trying to build my 64-32 cross-prefix, which I bootstrapped with a no-multilib 32-bit crossdev toolchain. Please see https://bugs.gentoo.org/show_bug.cgi?id=430722, especially the final two posts. I'd appreciate input on the correctness/feasibility of the various solutions I propose there. Apologies in advance for the verbose, stream-of-consciousness tone, it's more of a brainstorm than a bug at this point, and in retrospect, bugzilla probably wasn't the right place for it. -gmt
Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)
On 14/08/2012 02:57, Samuli Suominen wrote: I highly dislike libexec and have been moving stuff over /usr/lib/$pkg/ on daily basis So instead of discussing this you just decide you don't like the path and go with your preference? Honestly I would have preferred for this to go through council as _it already went through it once_ -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)
On Tue, 14 Aug 2012 12:57:13 +0300
Samuli Suominen ssuomi...@gentoo.org wrote:
On 14.08.2012 00:24, Diego Elio Pettenò wrote:
On 13/08/2012 11:29, Alexandre Rostovtsev wrote:
/usr/lib/pkgname/ is a directory like /usr/libexec/ or
even /bin. It shares absolutely zero things with the arch-specific
$libdir ,or lib64/.
Yes I know that FHS allows it. I still think it would be cleaner to
use /usr/libexec.
I highly dislike libexec and have been moving stuff
over /usr/lib/$pkg/ on daily basis
I believe we should be keeping «aligned» paths somewhere rather than
randomly moving stuff by hand. If you're saying that /usr/lib/${PN} ==
libexec, maybe we should put that into PMS as --libexecdir=?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)
On 14.08.2012 16:35, Diego Elio Pettenò wrote: On 14/08/2012 02:57, Samuli Suominen wrote: I highly dislike libexec and have been moving stuff over /usr/lib/$pkg/ on daily basis So instead of discussing this you just decide you don't like the path and go with your preference? Honestly I would have preferred for this to go through council as _it already went through it once_ Sorry I was vague in that statement, I meant moving to both /usr/lib/ when suitable (and usually the default from upstream lately) and /usr/lib64/xfce* (Location of .so Xfce plugins) Xfce had compability code for finding plugins from /usr/libexec only for 4.10 series, and is marked as -DXFCE_DEPRECATED code, 4.12 will solely use /usr/lib64/xfce4/ I've done nothing against the status quo, only following sane reasoning and defaults from upstreams who have made a strong case for it being so, or when they have actually made it impossible without carrying custom patches forever So all good, I hope this cleared misunderstandings - Samuli
Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)
On 13.08.2012 19:55, Samuli Suominen wrote: [ ... ] I should mention that we have discussed this already, https://bugs.gentoo.org/show_bug.cgi?id=364375 Which was a result of long gentoo-dev ML thread, unfortunately my search foo failed and I couldn't find straight link to it Why should we threat /usr than / any different in this regard, there was large consensus /lib/udev should be used instead of /lib64/udev and udev.pc's udevdir= is the path for udev helpers, ELFs(!), and rules among other things It's completely fair to say that multilib-strict feature has been broken ever since, years. - Samuli
Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)
On 14.08.2012 17:05, Michał Górny wrote:
On Tue, 14 Aug 2012 12:57:13 +0300
Samuli Suominen ssuomi...@gentoo.org wrote:
On 14.08.2012 00:24, Diego Elio Pettenò wrote:
On 13/08/2012 11:29, Alexandre Rostovtsev wrote:
/usr/lib/pkgname/ is a directory like /usr/libexec/ or
even /bin. It shares absolutely zero things with the arch-specific
$libdir ,or lib64/.
Yes I know that FHS allows it. I still think it would be cleaner to
use /usr/libexec.
I highly dislike libexec and have been moving stuff
over /usr/lib/$pkg/ on daily basis
I believe we should be keeping «aligned» paths somewhere rather than
randomly moving stuff by hand. If you're saying that /usr/lib/${PN} ==
libexec, maybe we should put that into PMS as --libexecdir=?
I would agree to this.
Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)
On 14.08.2012 17:05, Michał Górny wrote:
On Tue, 14 Aug 2012 12:57:13 +0300
Samuli Suominen ssuomi...@gentoo.org wrote:
On 14.08.2012 00:24, Diego Elio Pettenò wrote:
On 13/08/2012 11:29, Alexandre Rostovtsev wrote:
/usr/lib/pkgname/ is a directory like /usr/libexec/ or
even /bin. It shares absolutely zero things with the arch-specific
$libdir ,or lib64/.
Yes I know that FHS allows it. I still think it would be cleaner to
use /usr/libexec.
I highly dislike libexec and have been moving stuff
over /usr/lib/$pkg/ on daily basis
I believe we should be keeping «aligned» paths somewhere rather than
randomly moving stuff by hand. If you're saying that /usr/lib/${PN} ==
libexec, maybe we should put that into PMS as --libexecdir=?
With a EAPI bump, of course, to prevent breakage.
Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)
On 14.08.2012 19:57, Samuli Suominen wrote: On 14.08.2012 16:35, Diego Elio Pettenò wrote: On 14/08/2012 02:57, Samuli Suominen wrote: I highly dislike libexec and have been moving stuff over /usr/lib/$pkg/ on daily basis So instead of discussing this you just decide you don't like the path and go with your preference? Honestly I would have preferred for this to go through council as _it already went through it once_ Sorry I was vague in that statement, I meant moving to both /usr/lib/ when suitable (and usually the default from upstream lately) and /usr/lib64/xfce* (Location of .so Xfce plugins) and possible couple of others than /usr/lib64/xfce*... meh, should really proof read my own msgs
Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)
On 14/08/2012 09:57, Samuli Suominen wrote: Sorry I was vague in that statement, I meant moving to both /usr/lib/ when suitable (and usually the default from upstream lately) and /usr/lib64/xfce* (Location of .so Xfce plugins) Xfce had compability code for finding plugins from /usr/libexec only for 4.10 series, and is marked as -DXFCE_DEPRECATED code, 4.12 will solely use /usr/lib64/xfce4/ I've done nothing against the status quo, only following sane reasoning and defaults from upstreams who have made a strong case for it being so, or when they have actually made it impossible without carrying custom patches forever For plugins (if they are plugins) we really need to use the $libdir as they are ABI-dependent, so I'm perfectly happy with moving them out of libexec (shouldn't have been there in the first place). I'd still would like a revisit by council for what concerns /usr/libexec though. I'm afraid that last time I let it slide after Kugelfang promised he would write a draft that never came, as we had issue with cups. In general, I'm in favour of using lib (and not $libdir) if they are _executables_, which means they are not loaded in the same address space of any other program. I'm just concerned of having another hundred directories in /usr/lib as that could slow down ld.so... -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] Proxy maintainer needed for sys-apps/lomoco
Bug 345351 (ready patch and active user intrested in proxy maintainership) And there is one more, search bugzie for lomoco (Would do it myself but seriously got no time.)
Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)
On Tue, 14 Aug 2012 20:03:50 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 13.08.2012 19:55, Samuli Suominen wrote: [ ... ] I should mention that we have discussed this already, https://bugs.gentoo.org/show_bug.cgi?id=364375 Which was a result of long gentoo-dev ML thread, unfortunately my search foo failed and I couldn't find straight link to it Why should we threat /usr than / any different in this regard, there was large consensus /lib/udev should be used instead of /lib64/udev and udev.pc's udevdir= is the path for udev helpers, ELFs(!), and rules among other things It's completely fair to say that multilib-strict feature has been broken ever since, years. well, i dont agree its fair :P it breaks on _pie_ executables, which are not that common if you dont run hardened. what is broken, and has been broken since years is multilib-strict + pie toolchain; a flaw in the multilib-strict detection system that gets confused by 'file' output on pie executables :) A.
[gentoo-dev] Last Rites: dev-db/pgpool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 # Aaron W. Swenson titanof...@gentoo.org (14 Aug 2012) # Obsolete. Superseded by dev-db/pgpool2. Removal 14 Sep 2012. # (Bug #431414) dev-db/pgpool - -- Mr. Aaron W. Swenson Gentoo Linux Developer Email: titanof...@gentoo.org GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0 GnuPG ID : D1BBFDA0 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAlAqkzkACgkQVxOqA9G7/aD5RQD/RkpA8KRbcOAYi0ixUdcjEZub y9iJ1OuKvqGnnzK/1YEA/1a8NDv9ylA4ioiIDRiE13l1P3RglhqCs994+x7UcZg9 =eSu+ -END PGP SIGNATURE-
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Tue, Aug 14, 2012 at 5:31 AM, Rich Freeman ri...@gentoo.org wrote: On Mon, Aug 13, 2012 at 11:24 PM, Greg KH gre...@gentoo.org wrote: On Thu, Aug 09, 2012 at 03:47:19PM -0400, Rich Freeman wrote: On Thu, Aug 9, 2012 at 3:24 PM, Canek Peláez Valdés can...@gmail.com wrote: I agree with Greg Kroah-Hartman: I actually like (and want) a vertically integrated, tightly coupled way of doing things. Well, if you completely agreed with him you wouldn't be running Gentoo (or Debian, or other general-purpose distros). He advocates that ordinary users should use more purpose-driven distros, where all of this stuff is less of an issue. That is not what I said, or mean at all. Given that I'm a Gentoo developer, and have been for a very long time, I find it very strange that you would think otherwise. I did clarify my post in a reply, linking to your post and of course stating that you could clarify. Your words were: I just don't think it can be done well, sorry, which is why I strongly recommend tightly-coupled distros for desktops for anyone (like Fedora or openSUSE or Ubuntu), and Debian or Gentoo only for servers or embedded systems where you know exactly what you are putting together, and why you are doing it that way. I'm not a big fan of putting words in mouths, so if I misread that than I apologize. In any case, I can't really argue much with that statement as-is, although I'd probably carve out an additional exception for enthusiasts or those who otherwise like to tinker under the hood. If you want strong vertical integration, you probably will never get as much of it with Gentoo as you might get with a tightly-coupled distro. You can get as much vertical integration with Gentoo as with any other distro. The problem (and I think this is the point Greg is trying to make) is that it will be harder (not impossible, just harder) if most of Gentoo developers really believe that every single possible combination of hardware, software, init systems, and even OS kernels should be supported. I myself believe that any Gentoo dev should support whatever the hell s/he wants to; I'm just interested in that if some of us want vertical integration, it should be easier to get. Right now every single Gentoo install from the official tree has OpenRC installed, because is pulled in by baselayout, and OpenRC also pulls sysvinit. And I'm not talking about some text files (even if they are executables) in /etc/init.d; I'm talking about executable binaries and libraries in every Gentoo install, even if the user has systemd, and they don't use OpenRC/sysvinit at all. Not to mention that they need to compile both packages if they ever upgrade (which doesn't happen that much, I agree). Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Questions about SystemD and OpenRC
Canek Peláez Valdés wrote: You can get as much vertical integration with Gentoo as with any other distro. The problem (and I think this is the point Greg is trying to make) is that it will be harder (not impossible, just harder) if most of Gentoo developers really believe that every single possible combination of hardware, software, init systems, and even OS kernels should be supported. And even if it isn't harder, the main point for *many* competent users is that they have to do it themselves. Many extremely skilled peers of mine simply do not want to. They tried to do it, just not on Gentoo, and they have been burnt so badly by whatever distribution they tried that they basically swear off Linux completely for lack of time messing around, and just buy fruit computers. I have always appreciated the ability to customize, and I want to do it. The framework for customization that is Gentoo easily surpasses everything else that I have seen, and that's thanks to all the developers. But it means nothing for someone who wants to open a box, switch on the power, and go online to $socialmediasite or $emailprovider. //Peter
Re: [gentoo-dev] Questions about SystemD and OpenRC
On 08/14/2012 09:14 PM, Peter Stuge wrote: But it means nothing for someone who wants to open a box, switch on the power, and go online to $socialmediasite or $emailprovider. Sabayon does a decent job for them. lu
Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only
On 08/14/2012 02:44 AM, Michał Górny wrote: Hello, As some of you may have noticed, lately introduced 'double include preventions' have caused changes in effective phase functions in a few ebuilds. Can't that be avoided by putting the EXPORT_FUNCTIONS call outside of the ifndef block? The function implementations themselves can be inside the ifndef block, since that only need to be sourced once. Also, often it is undesirable that change in inherits of an eclass may cause an undesired change of exported functions. To solve these problems, we are proposing the following: 1. If an ebuild does not provide an explicit phase function, the phase functions *directly exported* by *directly inherited* eclasses are used to find a suitable default, 2. Thus, if an eclass inherits another eclass and expects the phase functions of that eclass to be effective to the ebuild, it needs to create its own phase function and export it. This should make the ebuild behavior simpler to understand and saner. It should also fix the forementioned issues, and allow us to make the 'source eclasses only once'[1] proposal simpler. [1]:https://bugs.gentoo.org/show_bug.cgi?id=422533 I'm not sure that your cure isn't worse than the disease. -- Thanks, Zac
Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only
On Tue, 14 Aug 2012 12:46:30 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/14/2012 02:44 AM, Michał Górny wrote: Hello, As some of you may have noticed, lately introduced 'double include preventions' have caused changes in effective phase functions in a few ebuilds. Can't that be avoided by putting the EXPORT_FUNCTIONS call outside of the ifndef block? The function implementations themselves can be inside the ifndef block, since that only need to be sourced once. Isn't that an awful kind of undefined behavior? We're already on a slippery ground assuming that sourced data changes between inherits. Assuming EXPORT_FUNCS will work some other ugly way is even worse. Also, often it is undesirable that change in inherits of an eclass may cause an undesired change of exported functions. To solve these problems, we are proposing the following: 1. If an ebuild does not provide an explicit phase function, the phase functions *directly exported* by *directly inherited* eclasses are used to find a suitable default, 2. Thus, if an eclass inherits another eclass and expects the phase functions of that eclass to be effective to the ebuild, it needs to create its own phase function and export it. This should make the ebuild behavior simpler to understand and saner. It should also fix the forementioned issues, and allow us to make the 'source eclasses only once'[1] proposal simpler. [1]:https://bugs.gentoo.org/show_bug.cgi?id=422533 I'm not sure that your cure isn't worse than the disease. In any case, 2. should happen even now. Eclasses should be simple and predictable, and debugging random failures isn't something nice. Unless you're saying that adding phase functions overrides to work-around failures which you don't even understand is a good solution. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only
On Tue, 14 Aug 2012 11:44:49 +0200 Michał Górny mgo...@gentoo.org wrote: As some of you may have noticed, lately introduced 'double include preventions' have caused changes in effective phase functions in a few ebuilds. Also, often it is undesirable that change in inherits of an eclass may cause an undesired change of exported functions. The problem here is that eclasses aren't clearly split between utility and does stuff, so people are inheriting does stuff eclasses to get utilities. The fix is to stop having stupidly huge complicated eclasses; changing inherit behaviour is just wallpapering over the gaping hole. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only
On Tue, 14 Aug 2012 21:45:56 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 14 Aug 2012 11:44:49 +0200 Michał Górny mgo...@gentoo.org wrote: As some of you may have noticed, lately introduced 'double include preventions' have caused changes in effective phase functions in a few ebuilds. Also, often it is undesirable that change in inherits of an eclass may cause an undesired change of exported functions. The problem here is that eclasses aren't clearly split between utility and does stuff, so people are inheriting does stuff eclasses to get utilities. The fix is to stop having stupidly huge complicated eclasses; changing inherit behaviour is just wallpapering over the gaping hole. Soo, how do you propose to handle bug 422533 without changing inherit behavior? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only
On Tue, 14 Aug 2012 22:54:13 +0200 Michał Górny mgo...@gentoo.org wrote: On Tue, 14 Aug 2012 21:45:56 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 14 Aug 2012 11:44:49 +0200 Michał Górny mgo...@gentoo.org wrote: As some of you may have noticed, lately introduced 'double include preventions' have caused changes in effective phase functions in a few ebuilds. Also, often it is undesirable that change in inherits of an eclass may cause an undesired change of exported functions. The problem here is that eclasses aren't clearly split between utility and does stuff, so people are inheriting does stuff eclasses to get utilities. The fix is to stop having stupidly huge complicated eclasses; changing inherit behaviour is just wallpapering over the gaping hole. Soo, how do you propose to handle bug 422533 without changing inherit behavior? We can't change inherit behaviour in EAPI 5 anyway since it's a global scope function, so I was planning to ignore it and hope that by the time EAPI 6 comes along, people will have learned not to write huge eclasses that do more than one thing. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only
On 08/14/2012 10:56 PM, Ciaran McCreesh wrote: We can't change inherit behaviour in EAPI 5 anyway since it's a global scope function, so I was planning to ignore it and hope that by the time EAPI 6 comes along, people will have learned not to write huge eclasses that do more than one thing. great idea, let's wait 5 years then
Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only
On 08/14/2012 01:54 PM, Michał Górny wrote: On Tue, 14 Aug 2012 21:45:56 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 14 Aug 2012 11:44:49 +0200 Michał Górny mgo...@gentoo.org wrote: As some of you may have noticed, lately introduced 'double include preventions' have caused changes in effective phase functions in a few ebuilds. Also, often it is undesirable that change in inherits of an eclass may cause an undesired change of exported functions. The problem here is that eclasses aren't clearly split between utility and does stuff, so people are inheriting does stuff eclasses to get utilities. The fix is to stop having stupidly huge complicated eclasses; changing inherit behaviour is just wallpapering over the gaping hole. Ciaran's assessment sounds pretty accurate to me. Soo, how do you propose to handle bug 422533 without changing inherit behavior? Close it as WONTFIX. The ifndef thing that we're doing now seems like a reasonable approach. -- Thanks, Zac
Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only
On Tue, 14 Aug 2012 21:56:38 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 14 Aug 2012 22:54:13 +0200 Michał Górny mgo...@gentoo.org wrote: On Tue, 14 Aug 2012 21:45:56 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 14 Aug 2012 11:44:49 +0200 Michał Górny mgo...@gentoo.org wrote: As some of you may have noticed, lately introduced 'double include preventions' have caused changes in effective phase functions in a few ebuilds. Also, often it is undesirable that change in inherits of an eclass may cause an undesired change of exported functions. The problem here is that eclasses aren't clearly split between utility and does stuff, so people are inheriting does stuff eclasses to get utilities. The fix is to stop having stupidly huge complicated eclasses; changing inherit behaviour is just wallpapering over the gaping hole. Soo, how do you propose to handle bug 422533 without changing inherit behavior? We can't change inherit behaviour in EAPI 5 anyway since it's a global scope function, so I was planning to ignore it and hope that by the time EAPI 6 comes along, people will have learned not to write huge eclasses that do more than one thing. And why? I believe we have quite a clean rule that *EAPI goes before inherit*. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only
On Tue, 14 Aug 2012 23:09:55 +0200 Michał Górny mgo...@gentoo.org wrote: We can't change inherit behaviour in EAPI 5 anyway since it's a global scope function, so I was planning to ignore it and hope that by the time EAPI 6 comes along, people will have learned not to write huge eclasses that do more than one thing. And why? I believe we have quite a clean rule that *EAPI goes before inherit*. That rule will only start applying from EAPI 6 onwards. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only
On Tue, 14 Aug 2012 23:01:05 +0200 hasufell hasuf...@gentoo.org wrote: On 08/14/2012 10:56 PM, Ciaran McCreesh wrote: We can't change inherit behaviour in EAPI 5 anyway since it's a global scope function, so I was planning to ignore it and hope that by the time EAPI 6 comes along, people will have learned not to write huge eclasses that do more than one thing. great idea, let's wait 5 years then Sorry, but the Council voted down the you can have it immediately approach because people got upset about file extensions. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only
On Tue, 14 Aug 2012 14:09:17 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/14/2012 01:54 PM, Michał Górny wrote: On Tue, 14 Aug 2012 21:45:56 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 14 Aug 2012 11:44:49 +0200 Michał Górny mgo...@gentoo.org wrote: As some of you may have noticed, lately introduced 'double include preventions' have caused changes in effective phase functions in a few ebuilds. Also, often it is undesirable that change in inherits of an eclass may cause an undesired change of exported functions. The problem here is that eclasses aren't clearly split between utility and does stuff, so people are inheriting does stuff eclasses to get utilities. The fix is to stop having stupidly huge complicated eclasses; changing inherit behaviour is just wallpapering over the gaping hole. Ciaran's assessment sounds pretty accurate to me. Soo, how do you propose to handle bug 422533 without changing inherit behavior? Close it as WONTFIX. The ifndef thing that we're doing now seems like a reasonable approach. But you're aware that this 'reasonable approach' just made the whole problem by changing exported functions, right? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only
On Tue, 14 Aug 2012 23:51:17 +0200 Michał Górny mgo...@gentoo.org wrote: But you're aware that this 'reasonable approach' just made the whole problem by changing exported functions, right? No, what made the whole problem is awful eclasses that do far too many things. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only
On 08/14/2012 02:51 PM, Michał Górny wrote: On Tue, 14 Aug 2012 14:09:17 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/14/2012 01:54 PM, Michał Górny wrote: On Tue, 14 Aug 2012 21:45:56 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 14 Aug 2012 11:44:49 +0200 Michał Górny mgo...@gentoo.org wrote: As some of you may have noticed, lately introduced 'double include preventions' have caused changes in effective phase functions in a few ebuilds. Also, often it is undesirable that change in inherits of an eclass may cause an undesired change of exported functions. The problem here is that eclasses aren't clearly split between utility and does stuff, so people are inheriting does stuff eclasses to get utilities. The fix is to stop having stupidly huge complicated eclasses; changing inherit behaviour is just wallpapering over the gaping hole. Ciaran's assessment sounds pretty accurate to me. Soo, how do you propose to handle bug 422533 without changing inherit behavior? Close it as WONTFIX. The ifndef thing that we're doing now seems like a reasonable approach. But you're aware that this 'reasonable approach' just made the whole problem by changing exported functions, right? That just means that somebody made a mistake. They should have put the EXPORT_FUNCTIONS call *outside* of the ifndef block. Just educate people about the correct place to put the EXPORT_FUNCTIONS call, and that problem is solved. -- Thanks, Zac
