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
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
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
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
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
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
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
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
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
