Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)
El vie, 27-04-2012 a las 21:12 +0100, Ciaran McCreesh escribió: On Fri, 27 Apr 2012 21:58:24 +0200 Michał Górny mgo...@gentoo.org wrote: Of course, if we take the 'quick EAPI 5 route', it won't include anything useful. In the meantime, do we have a complete list of candidates for EAPI 5? Let's continue this on the PMS list. * user patches * EAPI parsing * the things that were left out of 4: + slot operator deps + profile IUSE * No -j1 for src_test * Remove deprecated stuff * Zero or one REQUIRED_USE operator These might be cheap now? * New bash version * Get a versionator replacement into the PM Could: https://bugs.gentoo.org/show_bug.cgi?id=408693 be handled also? Thanks signature.asc Description: This is a digitally signed message part
Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)
On Fri, 27 Apr 2012 21:12:27 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: * Get a versionator replacement into the PM Why are we trying to make PM a brick instead of keeping stuff modular? What does the eclass lack which could be provided by PM? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)
On Sat, 28 Apr 2012 10:52:07 +0200 Michał Górny mgo...@gentoo.org wrote: On Fri, 27 Apr 2012 21:12:27 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: * Get a versionator replacement into the PM Why are we trying to make PM a brick instead of keeping stuff modular? What does the eclass lack which could be provided by PM? Because trying to parse version formats correctly in bash is a huge pain, and versionator doesn't get it right (never mind that the rules were different when versionator was written). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)
What's changed from 2006 in version handling? Il giorno 28/apr/2012 11:39, Ciaran McCreesh ciaran.mccre...@googlemail.com ha scritto: On Sat, 28 Apr 2012 10:52:07 +0200 Michał Górny mgo...@gentoo.org wrote: On Fri, 27 Apr 2012 21:12:27 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: * Get a versionator replacement into the PM Why are we trying to make PM a brick instead of keeping stuff modular? What does the eclass lack which could be provided by PM? Because trying to parse version formats correctly in bash is a huge pain, and versionator doesn't get it right (never mind that the rules were different when versionator was written). -- Ciaran McCreesh What's changed from 2006 in version handling?
Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)
On Sat, 28 Apr 2012 10:09:01 + Francesco Riosa viv...@gmail.com wrote: What's changed from 2006 in version handling? The ordering rules, the handling of zeroes and the behaviour of suffixes. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Making user patches globally available
Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted: On 04/26/2012 03:08 PM, Duncan wrote: Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted: Also, don't forget to consider the possibility of interference between FEATURES=userpatch and epatch_user (applying same patches twice). The existing phaselock-file solution should continue to work there. Having the package manager interact with an eclass function like epatch_user is ugly, and it's unnecessary since we can pull all of the pieces into the package manager in EAPI 5. Any eclasses that currently call epatch_user can have a conditional like this: if has $EAPI 0 1 2 3 4 ; then epatch_user else apply_user_patches_here fi But that doesn't solve the problem of making it globally available, since it only applies to packages/eclasses that already call epatch_user for EAPIs thru current EAPI-4. In ordered to make it globally available, it cannot simply be an EAPI-5 thing, it must apply to all current ebuilds whether they (or an inherited eclass) call epatch_user or not. Which means that conflict with the existing epatch_user is unavoidable, since it will either try to run twice where it's already called, or it won't run at all where it's not. Tho I guess one solution to that would be to change the name of the patches dir for the new version, calling it /etc/portage/patches2/ or some such. Another solution could be to make the existing epatch_user call a no-op, and force post-src-prepare invocation on EAPIs 1-4. But both of these have problems in that they nullify the work done in existing ebuilds to locate the call correctly, before eautoreconf or whatever. Overall, the apply_user_patches_here approach [1] seems pretty reasonable to me. [1] http://archives.gentoo.org/gentoo-dev/ msg_c228be85e0c4e577ad194e6004d59062.xml With the requirements that if the ebuild never calls it, it's still run immediately after source_prepare, thus ensuring that it gets called, AND that calling either autoreconf or eautoreconf without calling apply-user-patches fit is a repoman-checked error, it looks like it should work, agreed. I think it might be better to die if it's not called in src_prepare, like Ciaran originally suggested. This ensures that people don't forget to call it when they are supposed to. That can work for EAPI-5, but what about existing ebuilds? Remember, the goal is global coverage without forcing an edit to every existing ebuild that doesn't yet call it either directly or via eclass. But I'm a bit wary as to the robustness. And without a mechanism to apply the patches at a particular point (arguably, post-src-prepare) even in the absence of a specific apply-user-patches-here call, we're back where we were without a global solution, but if the hard-invocation is done, then we're back to either inefficiently running eautoreconf twice or forced into doing likely failure-prone detection, thus the worry over robustness. It's no worse than epatch_user currently is. It's the responsibility of the person who overrides src_prepare to call eautoreconf or whatever else when necessary, so the package manager will not have the burden. Except that in ordered to make it global without touching existing ebuilds, the PM MUST shoulder the burden. THAT is where the robustness issues appear. The require-it-in-EAPI-5-plus-only solution will help longer term, but given that many core packages are to remain EAPI-0 for the foreseeable future, that could be a VERY long term indeed. Additionally, it only makes user confusion WORSE, since a user still won't know for sure whether his patches will apply to a particular ebuild without looking. Making it just work is the goal, and just doing it for EAPI-5+ is nice, but not really sufficient. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, 27 Apr 2012 14:15:35 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted: On 04/26/2012 03:08 PM, Duncan wrote: Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted: Also, don't forget to consider the possibility of interference between FEATURES=userpatch and epatch_user (applying same patches twice). The existing phaselock-file solution should continue to work there. Having the package manager interact with an eclass function like epatch_user is ugly, and it's unnecessary since we can pull all of the pieces into the package manager in EAPI 5. Any eclasses that currently call epatch_user can have a conditional like this: if has $EAPI 0 1 2 3 4 ; then epatch_user else apply_user_patches_here fi But that doesn't solve the problem of making it globally available, since it only applies to packages/eclasses that already call epatch_user for EAPIs thru current EAPI-4. In ordered to make it globally available, it cannot simply be an EAPI-5 thing, it must apply to all current ebuilds whether they (or an inherited eclass) call epatch_user or not. Which means that conflict with the existing epatch_user is unavoidable, since it will either try to run twice where it's already called, or it won't run at all where it's not. Tho I guess one solution to that would be to change the name of the patches dir for the new version, calling it /etc/portage/patches2/ or some such. Another solution could be to make the existing epatch_user call a no-op, and force post-src-prepare invocation on EAPIs 1-4. But both of these have problems in that they nullify the work done in existing ebuilds to locate the call correctly, before eautoreconf or whatever. We could finally decide it'll be a Portage internal feature, and modify epatch_user() to export some Portage-specific indication that user patches were applied. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, 27 Apr 2012 14:15:35 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: In ordered to make it globally available, it cannot simply be an EAPI-5 thing, it must apply to all current ebuilds whether they (or an inherited eclass) call epatch_user or not. Which means that conflict with the existing epatch_user is unavoidable, since it will either try to run twice where it's already called, or it won't run at all where it's not. In order to make it globally available, you put it in EAPI 5, and make the package mangler die at pretend time if the user has patches specified for a package that isn't EAPI 5. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On 04/27/2012 07:27 AM, Ciaran McCreesh wrote: On Fri, 27 Apr 2012 14:15:35 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: In ordered to make it globally available, it cannot simply be an EAPI-5 thing, it must apply to all current ebuilds whether they (or an inherited eclass) call epatch_user or not. Which means that conflict with the existing epatch_user is unavoidable, since it will either try to run twice where it's already called, or it won't run at all where it's not. In order to make it globally available, you put it in EAPI 5, and make the package mangler die at pretend time if the user has patches specified for a package that isn't EAPI 5. Or, have repoman assert that src_prepare contains an epatch_user call if EAPI is less than 5. -- Thanks, Zac
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, 27 Apr 2012 08:41:35 -0700 Zac Medico zmed...@gentoo.org wrote: In order to make it globally available, you put it in EAPI 5, and make the package mangler die at pretend time if the user has patches specified for a package that isn't EAPI 5. Or, have repoman assert that src_prepare contains an epatch_user call if EAPI is less than 5. Why bother? That's hideously error prone. We have a simple way that's guaranteed to work, and that is able to inform the user if their expectations can't be met. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On 04/27/2012 08:45 AM, Ciaran McCreesh wrote: On Fri, 27 Apr 2012 08:41:35 -0700 Zac Medico zmed...@gentoo.org wrote: In order to make it globally available, you put it in EAPI 5, and make the package mangler die at pretend time if the user has patches specified for a package that isn't EAPI 5. Or, have repoman assert that src_prepare contains an epatch_user call if EAPI is less than 5. Why bother? That's hideously error prone. We have a simple way that's guaranteed to work, and that is able to inform the user if their expectations can't be met. I suppose that we could do it both ways. The repoman check would be for people who want a practical approach that doesn't require all ebuilds to be converted to EAPI 5, and your strict die approach would be for people who want strictness and can afford to wait for the relevant ebuilds to be converted to EAPI 5. -- Thanks, Zac
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, 27 Apr 2012 08:55:49 -0700 Zac Medico zmed...@gentoo.org wrote: I suppose that we could do it both ways. The repoman check would be for people who want a practical approach that doesn't require all ebuilds to be converted to EAPI 5, and your strict die approach would be for people who want strictness and can afford to wait for the relevant ebuilds to be converted to EAPI 5. But there's no way the repoman check is going to give anything like reliable answers if you're involving eclasses... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On 04/27/2012 09:00 AM, Ciaran McCreesh wrote: On Fri, 27 Apr 2012 08:55:49 -0700 Zac Medico zmed...@gentoo.org wrote: I suppose that we could do it both ways. The repoman check would be for people who want a practical approach that doesn't require all ebuilds to be converted to EAPI 5, and your strict die approach would be for people who want strictness and can afford to wait for the relevant ebuilds to be converted to EAPI 5. But there's no way the repoman check is going to give anything like reliable answers if you're involving eclasses... Okay, so people who need reliable answers can go with your strict approach. Meanwhile, it's relatively easy to to a manual audit of the src_prepare function of each eclass. -- Thanks, Zac
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, 27 Apr 2012 09:08:06 -0700 Zac Medico zmed...@gentoo.org wrote: But there's no way the repoman check is going to give anything like reliable answers if you're involving eclasses... Okay, so people who need reliable answers can go with your strict approach. Meanwhile, it's relatively easy to to a manual audit of the src_prepare function of each eclass. Providing unreliable functionality just leads to whining and contortions when it doesn't work. This isn't a situation where compromise is necessary, so there's no reason not to just do it properly. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On 04/27/2012 09:11 AM, Ciaran McCreesh wrote: On Fri, 27 Apr 2012 09:08:06 -0700 Zac Medico zmed...@gentoo.org wrote: But there's no way the repoman check is going to give anything like reliable answers if you're involving eclasses... Okay, so people who need reliable answers can go with your strict approach. Meanwhile, it's relatively easy to to a manual audit of the src_prepare function of each eclass. Providing unreliable functionality just leads to whining and contortions when it doesn't work. This isn't a situation where compromise is necessary, so there's no reason not to just do it properly. Yeah, I guess you're right. ;-) -- Thanks, Zac
[gentoo-dev] Re: Making user patches globally available
On 27/04/12 17:15, Duncan wrote: Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted: Having the package manager interact with an eclass function like epatch_user is ugly, and it's unnecessary since we can pull all of the pieces into the package manager in EAPI 5. Any eclasses that currently call epatch_user can have a conditional like this: if has $EAPI 0 1 2 3 4 ; then epatch_user else apply_user_patches_here fi But that doesn't solve the problem of making it globally available, since it only applies to packages/eclasses that already call epatch_user for EAPIs thru current EAPI-4. In ordered to make it globally available, it cannot simply be an EAPI-5 thing, it must apply to all current ebuilds whether they (or an inherited eclass) call epatch_user or not. Which means that conflict with the existing epatch_user is unavoidable, since it will either try to run twice where it's already called, or it won't run at all where it's not. According to the source, calling it twice is perfectly safe.
Re: [gentoo-dev] Re: Making user patches globally available
On 04/27/2012 07:20 AM, Michał Górny wrote: We could finally decide it'll be a Portage internal feature, and modify epatch_user() to export some Portage-specific indication that user patches were applied. Since we've managed to survive up to this point without such a feature, I think it's worth the wait roll it into EAPI 5 and have a clean solution that doesn't rely on package manager interaction with eclasses. If we quickly draft an EAPI 5 spec, there's still have time to have it approved at the next council meeting. -- Thanks, Zac
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, 27 Apr 2012, Zac Medico wrote: Since we've managed to survive up to this point without such a feature, I think it's worth the wait roll it into EAPI 5 and have a clean solution that doesn't rely on package manager interaction with eclasses. If we quickly draft an EAPI 5 spec, there's still have time to have it approved at the next council meeting. Did I get it right, you are thinking about a special EAPI only for user patches? I'd say that the feature is not important enough to justify that. Ulrich
Re: [gentoo-dev] Re: Making user patches globally available
On 04/27/2012 11:01 AM, Ulrich Mueller wrote: On Fri, 27 Apr 2012, Zac Medico wrote: Since we've managed to survive up to this point without such a feature, I think it's worth the wait roll it into EAPI 5 and have a clean solution that doesn't rely on package manager interaction with eclasses. If we quickly draft an EAPI 5 spec, there's still have time to have it approved at the next council meeting. Did I get it right, you are thinking about a special EAPI only for user patches? I'd say that the feature is not important enough to justify that. Let's just say that it's within the realm of possibilities, and I consider it to be preferable to a solution which involves package manager interaction with epatch_user. -- Thanks, Zac
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, Apr 27, 2012 at 11:01 AM, Ulrich Mueller u...@gentoo.org wrote: On Fri, 27 Apr 2012, Zac Medico wrote: Since we've managed to survive up to this point without such a feature, I think it's worth the wait roll it into EAPI 5 and have a clean solution that doesn't rely on package manager interaction with eclasses. If we quickly draft an EAPI 5 spec, there's still have time to have it approved at the next council meeting. Did I get it right, you are thinking about a special EAPI only for user patches? I'd say that the feature is not important enough to justify that. Release early and often :) Ulrich
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, 27 Apr 2012 20:01:15 +0200 Ulrich Mueller u...@gentoo.org wrote: On Fri, 27 Apr 2012, Zac Medico wrote: Since we've managed to survive up to this point without such a feature, I think it's worth the wait roll it into EAPI 5 and have a clean solution that doesn't rely on package manager interaction with eclasses. If we quickly draft an EAPI 5 spec, there's still have time to have it approved at the next council meeting. Did I get it right, you are thinking about a special EAPI only for user patches? I'd say that the feature is not important enough to justify that. +1. Either we use EAPIs with some thinking or just drop that concept and move on to something else. There is a number of features waiting for new EAPI, and noone yet even considered them. But when it comes to marginal feature which many of devs don't even accept, it's enough to quickly release a new EAPI which most of the tree won't support. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On 04/27/2012 11:57 AM, Michał Górny wrote: On Fri, 27 Apr 2012 20:01:15 +0200 Ulrich Mueller u...@gentoo.org wrote: On Fri, 27 Apr 2012, Zac Medico wrote: Since we've managed to survive up to this point without such a feature, I think it's worth the wait roll it into EAPI 5 and have a clean solution that doesn't rely on package manager interaction with eclasses. If we quickly draft an EAPI 5 spec, there's still have time to have it approved at the next council meeting. Did I get it right, you are thinking about a special EAPI only for user patches? I'd say that the feature is not important enough to justify that. +1. Either we use EAPIs with some thinking or just drop that concept and move on to something else. There is a number of features waiting for new EAPI, and noone yet even considered them. But when it comes to marginal feature which many of devs don't even accept, it's enough to quickly release a new EAPI which most of the tree won't support. The fact that it's a marginal feature is exactly why I don't think it justifies adding a quick and dirty hack that introduces an interaction between the package manager an eclass function like epatch_user. On the other hand, if it's important enough to justify a quick and dirty hack in the package manager, then I'd argue that it's also important enough to justify a quick and clean EAPI bump. -- Thanks, Zac
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, 27 Apr 2012 20:01:15 +0200 Ulrich Mueller u...@gentoo.org wrote: Since we've managed to survive up to this point without such a feature, I think it's worth the wait roll it into EAPI 5 and have a clean solution that doesn't rely on package manager interaction with eclasses. If we quickly draft an EAPI 5 spec, there's still have time to have it approved at the next council meeting. Did I get it right, you are thinking about a special EAPI only for user patches? I'd say that the feature is not important enough to justify that. Didn't we have a few other cheap things lined up? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, 27 Apr 2012, Ciaran McCreesh wrote: Did I get it right, you are thinking about a special EAPI only for user patches? I'd say that the feature is not important enough to justify that. Didn't we have a few other cheap things lined up? Yes we do, and IMHO it would make much more sense if EAPI 5 would include them. (And of course, there are still the two features that were omitted from EAPI 4, namely slot-operator-deps and profile-iuse-injection.) Ulrich
Re: [gentoo-dev] Re: Making user patches globally available
On Fri, 27 Apr 2012 21:43:06 +0200 Ulrich Mueller u...@gentoo.org wrote: On Fri, 27 Apr 2012, Ciaran McCreesh wrote: Did I get it right, you are thinking about a special EAPI only for user patches? I'd say that the feature is not important enough to justify that. Didn't we have a few other cheap things lined up? Yes we do, and IMHO it would make much more sense if EAPI 5 would include them. (And of course, there are still the two features that were omitted from EAPI 4, namely slot-operator-deps and profile-iuse-injection.) Of course, if we take the 'quick EAPI 5 route', it won't include anything useful. In the meantime, do we have a complete list of candidates for EAPI 5? -- Best regards, Michał Górny signature.asc Description: PGP signature
EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)
On Fri, 27 Apr 2012 21:58:24 +0200 Michał Górny mgo...@gentoo.org wrote: Of course, if we take the 'quick EAPI 5 route', it won't include anything useful. In the meantime, do we have a complete list of candidates for EAPI 5? Let's continue this on the PMS list. * user patches * EAPI parsing * the things that were left out of 4: + slot operator deps + profile IUSE * No -j1 for src_test * Remove deprecated stuff * Zero or one REQUIRED_USE operator These might be cheap now? * New bash version * Get a versionator replacement into the PM -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Making user patches globally available
Nikos Chantziaras posted on Fri, 27 Apr 2012 18:55:12 +0300 as excerpted: On 27/04/12 17:15, Duncan wrote: Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted: Having the package manager interact with an eclass function like epatch_user is ugly, and it's unnecessary since we can pull all of the pieces into the package manager in EAPI 5. But that doesn't solve the problem of making it globally available, since it only applies to packages/eclasses that already call epatch_user for EAPIs thru current EAPI-4. In ordered to make it globally available, it cannot simply be an EAPI-5 thing, it must apply to all current ebuilds whether they (or an inherited eclass) call epatch_user or not. Which means that conflict with the existing epatch_user is unavoidable, since it will either try to run twice where it's already called, or it won't run at all where it's not. According to the source, calling it twice is perfectly safe. That's actually one of the points I've been making, that if we simply force an epatch_user at approximately post_src_prepare, the existing code already deals with multiple calls just fine. The problem appears if we then decide that we're going to do something with eautoreconf immediately thereafter. * if we just call it, we're potentially doing extra work both when the patch didn't require it, and when the ebuild already invoked eautoreconf after doing its own patching. * elif we try to somehow detect that it needs to be run, that's a huge amount of additional complexity we're now talking about adding to what WAS a simple globalization of already tested working code. * elif we try to force developers to call it at some point via repoman check or the like, thus letting them decide, then we're possibly looking at eapi5, and in any case, we just lost the point of the entire exercise, to make it global without forcing a touch of every existing ebuild in the tree that doesn't do it yet. Rock, hard place, with us between them! That's why I proposed up-thread that at least for now we go with the simple option, simply have the PM call epatch_user (either supplying its own internal function or sourcing the eclass to get the existing eclass version), and just punt on the eautoreconf stuff for now. As I said there, based on my experience anyway, that covers the for me at least 80-90% of use-cases where the patch isn't complex enough to require an eautoreconf, using code that's already known to be solid and well tested. For the remaining 10-20%, the old solution, copying the ebuild to an overlay and adding the patch calls and any other necessary modifications manually, still works. I'd rather take the good solution, the well tested code we have now, and apply it globally, yielding the 80-90% reduction in forced personal overlay ebuilds as a result, and continue to deal with the 10-20% than need eautoreconf or other processing manually, now, instead of waiting possibly forever for a perfect solution that might or might not ever come, even if in theory it could raise that 80-90% to 99%+. But Zac and a few others believe that what I called the good solution will result in a more or less continuous flood of bugs from people who expect epatch_user (or whatever replaces it) to just work for that perhaps 10-20% where eautoreconf is required as well, and don't believe it's an acceptable tradeoff. Since they're the devs dealing with the bugs, not me, that's a trump card I can't counter. They win. Unfortunately that means we're stuck waiting for a perfect solution that may never come, once again, or at least with an eapi5 solution that even when adopted won't reach global coverage for many many years to come. Oh, well... Unless you're talking about eautoreconf, not epatch_user. Actually, calling eautoreconf extra times should be safe. It'll just take longer, potentially MUCH longer, relative to the current merge time of some affected packages. (There's the question too, of what happens if eautoreconf is called on a non-autotools package. But at a suitably high level, that simply gets lumped in with the general robustness question on the whole approach.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: Making user patches globally available
On Wed, 25 Apr 2012 22:03:18 -0700 Zac Medico zmed...@gentoo.org wrote: On 04/25/2012 09:44 PM, Ryan Hill wrote: Yeah the whole idea here was to make user patches available without ebuild modifications or eclass dependence. Using the apply_user_patches_here approach [1] that Ciaran suggested, the ebuild wouldn't need any modification unless it overrides default_src_prepare. Which is a very large number of ebuilds. :) But it's a step in the right direction. There is not necessarily any eclass dependence, though the ebuild may call eclass functions such as eautoreconf when necessary. [1] http://archives.gentoo.org/gentoo-dev/msg_c228be85e0c4e577ad194e6004d59062.xml -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Re: Making user patches globally available
Ryan Hill posted on Wed, 25 Apr 2012 22:44:33 -0600 as excerpted: On Wed, 18 Apr 2012 22:41:39 +0100 David Leverton levert...@googlemail.com wrote: The point I was trying to get at was that it seems a bit heavyweight to rely on a whole eclass for a minor use-case, as well as a bit error-prone to expect people to remember it every time, but maybe that's the least bad option after all Yeah the whole idea here was to make user patches available without ebuild modifications or eclass dependence. Being a user of this functionality since name forgotten, unfortunately first introduced it with his bashrc hooks and the additional FEATURES=userpatch he used, and currently using a nasty hack to ensure that it gets run for every package, even those not calling base.eclass... IMO we're over-thinking this. Keep in mind that while being able to simply drop a patch in /etc/portage/patches/cat/pkg/ is very useful indeed, ultimately, all it does is eliminate the necessity of manually copying the ebuild to a personal overlay and setting up the patch to be applied via the ebuild itself. My suggestion is therefore to do the simple thing, just apply any patches found in the patches dir, and punt on the complicated do-we-eautoreconf- or-not thing. Just having the patches applied consistently will be a HUGE improvement from what we have at the moment, and it doesn't prevent people from falling back to the old copy-ebuild-to-overlay-and-modify method, should anything fancy, including eautoreconf, but of course also including all the other things people modify ebuilds for OTHER than simple patching, be needed. IOW, let's quit letting the perfect be the enemy of the good, and just get on with it, already. I know from experience that this eliminates a good 80-90% of what would otherwise be personal overlay ebuilds, here, and it's not as if it's an EITHER overlay OR patches dir thing, so let's just do it, and people who need anything fancier can still do the overlay thing they're doing now, while those just applying a simple patch no longer have to worry about whether dropping it in patches is enough or not. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: Making user patches globally available
On 04/25/2012 11:18 PM, Duncan wrote: IOW, let's quit letting the perfect be the enemy of the good, and just get on with it, already. If that means settling on something that's fragile and prone to lots of bug reports, then it's not really practical, because it wastes peoples time (and time is our most valuable resource). -- Thanks, Zac
[gentoo-dev] Re: Making user patches globally available
Zac Medico posted on Wed, 25 Apr 2012 23:26:24 -0700 as excerpted: On 04/25/2012 11:18 PM, Duncan wrote: IOW, let's quit letting the perfect be the enemy of the good, and just get on with it, already. If that means settling on something that's fragile and prone to lots of bug reports, then it's not really practical, because it wastes peoples time (and time is our most valuable resource). IMO it's trying to do too much with it that's the fragile bit. If all it does is the patching, but it /always/ does the patching (unlike the hit- and-miss we get now), and people know they need to use the overlay-ebuild method to do anything beyond patching, including if they need to re- invoke eautoreconf, then it should just work. Right now we're talking about all this fancy stuff, detecting when we need to automatically run eautoreconf, etc, and /that/ seems to me to be the fragile bit. Of course that's why I have preserve-libs turned off here as well. IMO it's a too complex solution to a simple problem, and cleaning up when it breaks is worse than simply dealing with the problem using current proven technology. But at least epatch-user doesn't break the modified ebuild in overlay method, like preserved-libs breaks the normal revdep-rebuild scans so they report no packages to rebuild. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: Making user patches globally available
On 04/26/2012 02:55 AM, Duncan wrote: Zac Medico posted on Wed, 25 Apr 2012 23:26:24 -0700 as excerpted: On 04/25/2012 11:18 PM, Duncan wrote: IOW, let's quit letting the perfect be the enemy of the good, and just get on with it, already. If that means settling on something that's fragile and prone to lots of bug reports, then it's not really practical, because it wastes peoples time (and time is our most valuable resource). IMO it's trying to do too much with it that's the fragile bit. If all it does is the patching, but it /always/ does the patching (unlike the hit- and-miss we get now), and people know they need to use the overlay-ebuild method to do anything beyond patching, including if they need to re- invoke eautoreconf, then it should just work. Right now we're talking about all this fancy stuff, detecting when we need to automatically run eautoreconf, etc, and /that/ seems to me to be the fragile bit. Ignoring the problem doesn't make it go away. If we ignore the problem, then we end up dealing with bug reports of the form FEATURES=userpatch doesn't work with this particular patch set until the end of time. Also, don't forget to consider the possibility of interference between FEATURES=userpatch and epatch_user (applying same patches twice). Overall, the apply_user_patches_here approach [1] seems pretty reasonable to me. [1] http://archives.gentoo.org/gentoo-dev/msg_c228be85e0c4e577ad194e6004d59062.xml -- Thanks, Zac
Re: [gentoo-dev] Re: Making user patches globally available
On Thu, 26 Apr 2012 06:18:32 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: My suggestion is therefore to do the simple thing, just apply any patches found in the patches dir, and punt on the complicated do-we-eautoreconf- or-not thing. Agreed. Just make sure the feature will be only used for ebuilds not calling epatch_user manually or through the eclass. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On 04/26/2012 11:27 AM, Michał Górny wrote: On Thu, 26 Apr 2012 06:18:32 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: My suggestion is therefore to do the simple thing, just apply any patches found in the patches dir, and punt on the complicated do-we-eautoreconf- or-not thing. Agreed. Just make sure the feature will be only used for ebuilds not calling epatch_user manually or through the eclass. So the package manager is supposed to interact with an eclass function? That's pretty ugly. Why not just roll out a quick EAPI 5 that adds support for the apply_user_patches_here approach [1]? http://archives.gentoo.org/gentoo-dev/msg_c228be85e0c4e577ad194e6004d59062.xml -- Thanks, Zac
Re: [gentoo-dev] Re: Making user patches globally available
On Thu, 26 Apr 2012 11:43:37 -0700 Zac Medico zmed...@gentoo.org wrote: On 04/26/2012 11:27 AM, Michał Górny wrote: On Thu, 26 Apr 2012 06:18:32 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: My suggestion is therefore to do the simple thing, just apply any patches found in the patches dir, and punt on the complicated do-we-eautoreconf- or-not thing. Agreed. Just make sure the feature will be only used for ebuilds not calling epatch_user manually or through the eclass. So the package manager is supposed to interact with an eclass function? That's pretty ugly. Why not just roll out a quick EAPI 5 that adds support for the apply_user_patches_here approach [1]? http://archives.gentoo.org/gentoo-dev/msg_c228be85e0c4e577ad194e6004d59062.xml 1) Because it's ugly hack, 2) it will have to interact with epatch_user anyway (at least to avoid applying patches twice), 3) it will work only for new/modified ebuilds so won't differ at all from using epatch_user(). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On Thu, 26 Apr 2012 20:50:02 +0200 Michał Górny mgo...@gentoo.org wrote: So the package manager is supposed to interact with an eclass function? That's pretty ugly. Why not just roll out a quick EAPI 5 that adds support for the apply_user_patches_here approach [1]? http://archives.gentoo.org/gentoo-dev/msg_c228be85e0c4e577ad194e6004d59062.xml 1) Because it's ugly hack, Awww. You say that about everything with my name on it. 2) it will have to interact with epatch_user anyway (at least to avoid applying patches twice), 3) it will work only for new/modified ebuilds so won't differ at all from using epatch_user(). Not if we kill epatch_user... Not like it works properly anyway, and it's better to have a works properly or not at all feature than one that breaks randomly. The package mangler could even make it fatal (at pretend time, no less) if someone wants to apply user patches to an ebuild whose EAPI doesn't support it. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Making user patches globally available
Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted: On 04/26/2012 02:55 AM, Duncan wrote: Zac Medico posted on Wed, 25 Apr 2012 23:26:24 -0700 as excerpted: On 04/25/2012 11:18 PM, Duncan wrote: IOW, let's quit letting the perfect be the enemy of the good If that means settling on something that's fragile and prone to lots of bug reports, then it's not really practical IMO[,] If all it does is the patching, but it /always/ does the patching[,] and people know they need to use the overlay-ebuild method to do anything beyond patching, [including eautoreconf,] then it should just work. Ignoring the problem doesn't make it go away. If we ignore the problem, then we end up dealing with bug reports of the form FEATURES=userpatch doesn't work with this particular patch set until the end of time. Standard boilerplate resolved/DUP, pointing to the first one, resolved like this: NOTABUG/INVALID. The feature does what it says on the label and is working as designed. The files are patched and the build bails out if the patch fails. The userpatch feature is deliberately limited to patching, thus keeping the problem manageable and the code transparent and maintainable. For anything fancy, including patches that need eautoreconf called afterward, the userpatch feature isn't the right tool. Copy the ebuild to an overlay and edit it as necessary to both apply the patch and eautoreconf or whatever else needs done afterward. Also, don't forget to consider the possibility of interference between FEATURES=userpatch and epatch_user (applying same patches twice). The existing phaselock-file solution should continue to work there. Test for the existence of a file and punt if it's found; touch the file on first invocation. The only caveat is that the existing eclass solution has changed the filename before. Once the corresponding feature exists, both the eclass and the feature will have to use the same filename so as not to conflict with each other, thereby effectively locking down the name and preventing further changes to it. Overall, the apply_user_patches_here approach [1] seems pretty reasonable to me. [1] http://archives.gentoo.org/gentoo-dev/ msg_c228be85e0c4e577ad194e6004d59062.xml With the requirements that if the ebuild never calls it, it's still run immediately after source_prepare, thus ensuring that it gets called, AND that calling either autoreconf or eautoreconf without calling apply-user- patches first is a repoman-checked error, it looks like it should work, agreed. But I'm a bit wary as to the robustness. And without a mechanism to apply the patches at a particular point (arguably, post-src-prepare) even in the absence of a specific apply-user-patches-here call, we're back where we were without a global solution, but if the hard-invocation is done, then we're back to either inefficiently running eautoreconf twice or forced into doing likely failure-prone detection, thus the worry over robustness. But of course he who codes, decides. We have existing and already proven code for the simple case, but if someone actually codes that complex approach, and it actually does both get us global coverage and avoid duplicated autoreconf runs, without hard to track down failures, I for one will certainly bless them! =:^) I just don't want to have to wait until kingdom come for the perfect solution, when we already have a demonstrated good enough 80-90% of the time solution ready to roll out globally, if we'd just do it. It's also worth pointing out that nothing prevents rolling out the good enough solution right away, then growing the complexity to cover the harder autoreconf cases when a solution for them actually gets coded. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: Making user patches globally available
On 04/26/2012 03:08 PM, Duncan wrote: Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted: Also, don't forget to consider the possibility of interference between FEATURES=userpatch and epatch_user (applying same patches twice). The existing phaselock-file solution should continue to work there. Test for the existence of a file and punt if it's found; touch the file on first invocation. The only caveat is that the existing eclass solution has changed the filename before. Once the corresponding feature exists, both the eclass and the feature will have to use the same filename so as not to conflict with each other, thereby effectively locking down the name and preventing further changes to it. Having the package manager interact with an eclass function like epatch_user is ugly, and it's unnecessary since we can pull all of the pieces into the package manager in EAPI 5. Any eclasses that currently call epatch_user can have a conditional like this: if has $EAPI 0 1 2 3 4 ; then epatch_user else apply_user_patches_here fi Overall, the apply_user_patches_here approach [1] seems pretty reasonable to me. [1] http://archives.gentoo.org/gentoo-dev/ msg_c228be85e0c4e577ad194e6004d59062.xml With the requirements that if the ebuild never calls it, it's still run immediately after source_prepare, thus ensuring that it gets called, AND that calling either autoreconf or eautoreconf without calling apply-user- patches first is a repoman-checked error, it looks like it should work, agreed. I think it might be better to die if it's not called in src_prepare, like Ciaran originally suggested. This ensures that people don't forget to call it when they are supposed to. But I'm a bit wary as to the robustness. And without a mechanism to apply the patches at a particular point (arguably, post-src-prepare) even in the absence of a specific apply-user-patches-here call, we're back where we were without a global solution, but if the hard-invocation is done, then we're back to either inefficiently running eautoreconf twice or forced into doing likely failure-prone detection, thus the worry over robustness. It's no worse than epatch_user currently is. It's the responsibility of the person who overrides src_prepare to call eautoreconf or whatever else when necessary, so the package manager will not have the burden. -- Thanks, Zac
[gentoo-dev] Re: Making user patches globally available
On Wed, 18 Apr 2012 22:41:39 +0100 David Leverton levert...@googlemail.com wrote: The point I was trying to get at was that it seems a bit heavyweight to rely on a whole eclass for a minor use-case, as well as a bit error-prone to expect people to remember it every time, but maybe that's the least bad option after all Yeah the whole idea here was to make user patches available without ebuild modifications or eclass dependence. -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On 04/25/2012 09:44 PM, Ryan Hill wrote: On Wed, 18 Apr 2012 22:41:39 +0100 David Leverton levert...@googlemail.com wrote: The point I was trying to get at was that it seems a bit heavyweight to rely on a whole eclass for a minor use-case, as well as a bit error-prone to expect people to remember it every time, but maybe that's the least bad option after all Yeah the whole idea here was to make user patches available without ebuild modifications or eclass dependence. Using the apply_user_patches_here approach [1] that Ciaran suggested, the ebuild wouldn't need any modification unless it overrides default_src_prepare. There is not necessarily any eclass dependence, though the ebuild may call eclass functions such as eautoreconf when necessary. [1] http://archives.gentoo.org/gentoo-dev/msg_c228be85e0c4e577ad194e6004d59062.xml -- Thanks, Zac
[gentoo-dev] Re: Making user patches globally available
Ryan Hill wrote: Zac Medico wrote: Funtoo has support for FEATURES=localpatch, which does the epatch_user thing before src_prepare. I think it should really go after src_prepare, in order to apply patches after those that src_prepare may apply (avoiding possible conflicts). I agree. The reason that Funtoo's FEATURES=localpatch applies patches before src_prepare is that it's common for eautoreconf to be called inside src_prepare, and applying patches after src_prepare can create a need to call eautoreconf a second time. Well that could waste a bit of time but is pretty much harmless, no? And the existing usages of epatch_user (other than autotools-utils) don't eautoreconf anyways, nor should they in case the package doesn't use autotools. Zac Medico wrote: The nice thing about delegating the epatch_user call to the ebuild/eclass is that it allows the epatch_user call be positioned directly before an eautoreconf call when appropriate. It seems there's two major cases, with autotools or without. In either case, epatch_user should be called after Gentoo patches have been applied. Why not make epatch_user set a variable to indicate that patches have been applied, and only apply the patches on the first call? Then eautoreconf could call it before calling autoconf (and the ebuild wouldn't need to worry about it.) And any custom src_prepare function could call it when needed, if it needed to be done during the phase, and not after. After src_prepare, the PM could just call it unconditionally, since it will not apply the patches again, if it's already been called by the ebuild. Does that make sense? Steve. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: Making user patches globally available
On 04/22/2012 10:04 PM, Steven J Long wrote: It seems there's two major cases, with autotools or without. In either case, epatch_user should be called after Gentoo patches have been applied. Why not make epatch_user set a variable to indicate that patches have been applied, and only apply the patches on the first call? Then eautoreconf could call it before calling autoconf (and the ebuild wouldn't need to worry about it.) And any custom src_prepare function could call it when needed, if it needed to be done during the phase, and not after. After src_prepare, the PM could just call it unconditionally, since it will not apply the patches again, if it's already been called by the ebuild. Does that make sense? Yeah, sounds roughly equivalent to Ciaran's suggested apply_user_patches_here approach [1], except that Ciaran suggested to make it an error if src_prepare doesn't call apply_user_patches_here (so people don't forget to call it when they should). [1] http://archives.gentoo.org/gentoo-dev/msg_c228be85e0c4e577ad194e6004d59062.xml -- Thanks, Zac
[gentoo-dev] Re: Making user patches globally available
On Sun, 15 Apr 2012 01:35:40 -0700 Zac Medico zmed...@gentoo.org wrote: On 04/15/2012 01:16 AM, Ryan Hill wrote: Right now we have support in some packages for user patches - those being patches dropped into /etc/portage/patches/pkgname/ - which are automatically applied. Because this feature is implemented by epatch_user() in eutils.eclass, it is only available for ebuilds that inherit eutils and explicitly call epatch_user or inherit another eclass that calls it in an exported phase (eg. base). The end result is a very inconsistent experience, where user patches may or may not work not only on a package-by-package basis, but ebuild-by-ebuild. Is there any reason why this couldn't just be done in the package manager, making user patches available for all ebuilds without code changes? Funtoo has support for FEATURES=localpatch, which does the epatch_user thing before src_prepare. I think it should really go after src_prepare, in order to apply patches after those that src_prepare may apply (avoiding possible conflicts). I agree. The reason that Funtoo's FEATURES=localpatch applies patches before src_prepare is that it's common for eautoreconf to be called inside src_prepare, and applying patches after src_prepare can create a need to call eautoreconf a second time. Well that could waste a bit of time but is pretty much harmless, no? And the existing usages of epatch_user (other than autotools-utils) don't eautoreconf anyways, nor should they in case the package doesn't use autotools. -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Re: Making user patches globally available
On Sun, 15 Apr 2012 16:53:04 +0800 Patrick Lauer patr...@gentoo.org wrote: On 04/15/12 16:16, Ryan Hill wrote: Right now we have support in some packages for user patches - those being patches dropped into /etc/portage/patches/pkgname/ - which are automatically applied. Because this feature is implemented by epatch_user() in eutils.eclass, it is only available for ebuilds that inherit eutils and explicitly call epatch_user or inherit another eclass that calls it in an exported phase (eg. base). The end result is a very inconsistent experience, where user patches may or may not work not only on a package-by-package basis, but ebuild-by-ebuild. Is there any reason why this couldn't just be done in the package manager, making user patches available for all ebuilds without code changes? From a debugging / bug wrangling perspective it's bad because there's no way for me to see if someone accidentally patched in something unexpected. (And we do have creative users :) ) Surprise, that's already the case for anything running base_src_prepare which is a sizable chunk of the tree, including anything inheriting kde or qt4 eclasses, xfconf, and perl-module. It's a neat feature, but I'm moderately opposed to it unless we can get reporting in place so I can definitely see (e.g. from a logfile or error message) that there's been some ebuild modifications. It's right there in the build log. -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making user patches globally available
On 04/15/2012 02:03 AM, Ryan Hill wrote: The reason that Funtoo's FEATURES=localpatch applies patches before src_prepare is that it's common for eautoreconf to be called inside src_prepare, and applying patches after src_prepare can create a need to call eautoreconf a second time. Well that could waste a bit of time but is pretty much harmless, no? I don't know. Somebody who's familiar with eautoreconf will have to comment. And the existing usages of epatch_user (other than autotools-utils) don't eautoreconf anyways, nor should they in case the package doesn't use autotools. I haven't really studied the usage patterns. The nice thing about delegating the epatch_user call to the ebuild/eclass is that it allows the epatch_user call be positioned directly before an eautoreconf call when appropriate. -- Thanks, Zac
Re: [gentoo-dev] Re: Making user patches globally available
On 2012-04-15, at 5:03 AM, Ryan Hill dirtye...@gentoo.org wrote: On Sun, 15 Apr 2012 01:35:40 -0700 Zac Medico zmed...@gentoo.org wrote: On 04/15/2012 01:16 AM, Ryan Hill wrote: Right now we have support in some packages for user patches - those being patches dropped into /etc/portage/patches/pkgname/ - which are automatically applied. Because this feature is implemented by epatch_user() in eutils.eclass, it is only available for ebuilds that inherit eutils and explicitly call epatch_user or inherit another eclass that calls it in an exported phase (eg. base). The end result is a very inconsistent experience, where user patches may or may not work not only on a package-by-package basis, but ebuild-by-ebuild. Is there any reason why this couldn't just be done in the package manager, making user patches available for all ebuilds without code changes? Funtoo has support for FEATURES=localpatch, which does the epatch_user thing before src_prepare. I think it should really go after src_prepare, in order to apply patches after those that src_prepare may apply (avoiding possible conflicts). I agree. The reason that Funtoo's FEATURES=localpatch applies patches before src_prepare is that it's common for eautoreconf to be called inside src_prepare, and applying patches after src_prepare can create a need to call eautoreconf a second time. Well that could waste a bit of time but is pretty much harmless, no? And the existing usages of epatch_user (other than autotools-utils) don't eautoreconf anyways, nor should they in case the package doesn't use autotools. the existing use of epatch_user allow you to put the call after current epatchez and before the eautoreconf call.. I agree tho -- an automatic call to eautoreconf could be triggered by features=localpatch whenever there are patches and autotools.eclass is inherited. also, any user patches applied could be cat'd to the build log, to allow for debugging
[gentoo-dev] Re: Making user patches globally available
Sergei Trofimovich posted on Sun, 15 Apr 2012 12:25:12 +0300 as excerpted:
On Sun, 15 Apr 2012 16:53:04 +0800 Patrick Lauer patr...@gentoo.org
wrote:
On 04/15/12 16:16, Ryan Hill wrote:
Right now we have support in some packages for user patches - those
being patches dropped into /etc/portage/patches/pkgname/ - which are
automatically applied. Because this feature is implemented by
epatch_user() in eutils.eclass, it is only available for ebuilds that
inherit eutils and explicitly call epatch_user or inherit another
eclass that calls it in an exported phase (eg. base). The end result
is a very inconsistent experience,
where user patches may or may not work not only on a
package-by-package basis, but ebuild-by-ebuild.
Is there any reason why this couldn't just be done in the package
manager, making user patches available for all ebuilds without code
changes?
+100
From a debugging / bug wrangling perspective it's bad because there's
no way for me to see if someone accidentally patched in something
unexpected. (And we do have creative users :) )
The existing infrastructure already reports the application of user
patches. I know, as I use it regularly, and rely on the ebuild output to
double-check that it's being applied, when something goes wrong.
It's a neat feature, but I'm moderately opposed to it unless we can get
reporting in place so I can definitely see (e.g. from a logfile or
error message) that there's been some ebuild modifications.
Then you should be all for it, since that's already there so your only
condition is to continue existing practice when epatch_user is applied
globally. =:^)
For an advanced user it's already just a matter of adding
post_src_prepare() {
epatch_user
}
to '/etc/portage/bashrc' and screw thing up, right?
That works for many ebuilds, but unfortunately not all, as base.eclass
isn't inherited by all, meaning epatch_user isn't always recognized. =:^(
I hacked it up to work a bit more reliably, here, but it's ugly (lots of
sourcing complaints to /dev/null in ordered to get it from the eclass
into the environment and avoid having to manually maintain it; jed are my
initials, I often use them to avoid namespace collision and ease
grepping):
$cat /etc/portage/bashrc
post_src_prepare () {
. epatch_jed
}
$cat /usr/local/sbin/epatch_jed
# user-patch helper, in case base.eclass isn't inherited
type epatch_user /dev/null 21 epatch_user || {
bash -c . $PORTDIR/eclass/eutils.eclass 2- ; epatch_user
}
$
I'm not absolutely sure that catches everything, and it's a nasty fragile
hack (I had problems with bash-var read-only errors shorting out the
process at one point), but it seems to be working for everything I've
needed it for including ebuilds that don't inherit base.eclass, at this
point.
eutils.eclass:epatch_user() could be more noisy (ewarn?) when applies
user patches. That way you could easier see something odd happening in
build.log.
Your (I think) idea elsewhere, to cat the patches into the log, is
interesting. But that could arguably be TOO noisy for big patches, say
entire feature-adds. Maybe add yet another portage command-line option
to (en|dis)able it? That way the current output could flag the
possibility, and wranglers/maintainers could request the longer output if
necessary.
--
Duncan - List replies preferred. No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master. Richard Stallman
