[gentoo-dev] Making user patches globally available

[gentoo-dev] Making user patches globally available

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

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?


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Making user patches globally available

[Zac Medico]

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

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.
-- 
Thanks,
Zac

[gentoo-dev] Re: Making user patches globally available

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]

On Sun, 15 Apr 2012 01:35:40 -0700
Zac Medico <zmedico@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Making user patches globally available

[Zac Medico]

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

[Ian Stakenvicius]

On 2012-04-15, at 5:03 AM, Ryan Hill <dirtyepic@gentoo.org> wrote:

> On Sun, 15 Apr 2012 01:35:40 -0700
> Zac Medico <zmedico@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

[Steven J Long]

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

[Zac Medico]

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: Re: Making user patches globally available

[Steven J Long]

Zac Medico wrote:
> 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

Yeah, I saw that, but given that this would be standardisation around an 
EAPI bump, I don't see the point in changing the name of the function to 
mean exactly the same thing, only to make it much more inconvenient in 
usage.

I feel there needs to be more thinking about what you mentioned, ie around 
the lines of "user-patches are applied on top of Gentoo-patched sources." 
This makes much more sense in process terms, since user-patches are more 
likely to be included in Gentoo-patches, and thus easier to handle for 
submission upstream. The alternative (user-patches applied to vanilla 
sources) has much more likelihood for bad interaction with Gentoo patches or 
changes.

If we stipulate that src_prepare transforms upstream sources into Gentoo-
official sources, then it only makes sense to epatch_user thereafter, and 
there's no point burdening the ebuild, or its developer, with that task.
It also makes ebuilds much cleaner to read.

Where you have a build-system that requires epatch_user part way through 
src_prepare, it's up to the ebuild, or more likely eclass for that build-
system, to call it at the appropriate time. (autoconf ebuilds clearly should 
just inherit whatever eclass the team tells them to, and stop messing 
around.)

In any event, specifying that the PM only calls epatch_user after 
src_prepare if there are user-patches, and it hasn't been called already 
(this is easiest done within epatch_user, ofc) allows ebuild or eclass 
developers to override the default easily, while still keeping things easy 
for most ebuilds.

eg: so far I've heard that: epatch_user && eautoreconf 
..is desired behaviour, so I guess you want logic like:

if ((${#USER_PATCHES[*]})); then
   ((applied_user_patches)) || {
      <.. apply the patches || die ..>
      applied_user_patches=1
   }
   return 0
else return 1
fi

Given something like the above, the addition of a simple[1]: epatch_user
..to eautoreconf before the call to autoreconf, and after src_prepare in 
ebuild.sh, cannot do any harm, and ensures that sources are patched without 
adding any cruft to ebuilds.

I also think there would be merit in optionally including any user-patches 
with binpkgs. This would be useful for transparency, ie debugging and 
licensing concerns with respect to modified sources.

Regards,
Steve.

PS As you know, ofc, patches against vanilla sources can be done in a 
pre_src_prepare bashrc hook, if one really has to for custom builds. I don't 
think anyone's talking about implementing them; or should they be on the 
table too?

[1] Yes, EAPI-dependent, so might need eg:
case $EAPI in 5|6) epatch_user;; esac
..depending on what else is happening, but simple in the sense that we don't 
care about its return value in these contexts.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Making user patches globally available

[Jeroen Roovers]

On Sun, 15 Apr 2012 01:35:40 -0700
Zac Medico <zmedico@gentoo.org> 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).

So in some future EAPI, src_patch() will be run before src_prepare()?


     jer

Re: [gentoo-dev] Making user patches globally available

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 727 bytes --]

On Wednesday 18 April 2012 12:59:13 Jeroen Roovers wrote:
> On Sun, 15 Apr 2012 01:35:40 -0700 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).
> 
> So in some future EAPI, src_patch() will be run before src_prepare()?

i don't think Zac mentioned PMS/EAPI anywhere ... just what Funtoo has done 
locally

i'm not sure splitting patches out of src_prepare into a dedicated src_patch 
step would benefit that much.  often times, you need to mangle the code 
before/after patching.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Making user patches globally available

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

On Wed, 18 Apr 2012 13:39:59 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> i'm not sure splitting patches out of src_prepare into a dedicated
> src_patch step would benefit that much.  often times, you need to
> mangle the code before/after patching.

Right. If we were going to take the EAPI route with this, the easiest
way would probably be to require that overridden src_prepare functions
call a magic function called "apply_user_patches_here" (and to barf if
a src_prepare finished without having called that function).

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Making user patches globally available

[Zac Medico]

On 04/18/2012 10:41 AM, Ciaran McCreesh wrote:
> On Wed, 18 Apr 2012 13:39:59 -0400
> Mike Frysinger<vapier@gentoo.org>  wrote:
>> i'm not sure splitting patches out of src_prepare into a dedicated
>> src_patch step would benefit that much.  often times, you need to
>> mangle the code before/after patching.
>
> Right. If we were going to take the EAPI route with this, the easiest
> way would probably be to require that overridden src_prepare functions
> call a magic function called "apply_user_patches_here" (and to barf if
> a src_prepare finished without having called that function).

Also, maybe apply_user_patches_here should have a special return value 
if there are no patches to be applied? That way, src_prepare can avoid 
an eautoreconf call if there are no patches.
-- 
Thanks,
Zac

Re: [gentoo-dev] Making user patches globally available

[David Leverton]

Zac Medico wrote:
> Also, maybe apply_user_patches_here should have a special return value
> if there are no patches to be applied? That way, src_prepare can avoid
> an eautoreconf call if there are no patches.

Does that imply that every ebuild for an autotools-based package would 
be expected to have an "apply_user_patches_here && eautoreconf" line, 
just in case the user might want to add custom patches?  It could be 
exported by autotools.eclass, but even so, requiring every autotools 
ebuild to inherit the eclass even if it doesn't have any effect by 
default seems a bit unfortunate.

Re: [gentoo-dev] Making user patches globally available

[Zac Medico]

On 04/18/2012 11:34 AM, David Leverton wrote:
> Zac Medico wrote:
>> Also, maybe apply_user_patches_here should have a special return value
>> if there are no patches to be applied? That way, src_prepare can avoid
>> an eautoreconf call if there are no patches.
>
> Does that imply that every ebuild for an autotools-based package would
> be expected to have an "apply_user_patches_here && eautoreconf" line,
> just in case the user might want to add custom patches? It could be
> exported by autotools.eclass, but even so, requiring every autotools
> ebuild to inherit the eclass even if it doesn't have any effect by
> default seems a bit unfortunate.

Isn't that just a consequence of how autotools works? Do you have a 
better alternative?
-- 
Thanks,
Zac

Re: [gentoo-dev] Making user patches globally available

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

On Wed, 18 Apr 2012 12:41:32 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> On 04/18/2012 11:34 AM, David Leverton wrote:
> > Zac Medico wrote:
> >> Also, maybe apply_user_patches_here should have a special return
> >> value if there are no patches to be applied? That way, src_prepare
> >> can avoid an eautoreconf call if there are no patches.
> >
> > Does that imply that every ebuild for an autotools-based package
> > would be expected to have an "apply_user_patches_here &&
> > eautoreconf" line, just in case the user might want to add custom
> > patches? It could be exported by autotools.eclass, but even so,
> > requiring every autotools ebuild to inherit the eclass even if it
> > doesn't have any effect by default seems a bit unfortunate.
> 
> Isn't that just a consequence of how autotools works? Do you have a 
> better alternative?

And it implies autotools on every, even very simple patch.
autotools-utils does that much better but everyone likes reinventing
wheels.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Making user patches globally available

[David Leverton]

Zac Medico wrote:
> Isn't that just a consequence of how autotools works? Do you have a
> better alternative?

Maaaybe letting the package manager know how to run autotools if 
necessary?  There's already built-in autotools knowledge in that econf 
is in practice autotools-specific.  On the other hand, the eclass logic 
isn't trivial, so unless a simplified subset would be adequate for this 
usage it's probably best left as it is.

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

[gentoo-dev] Re: Making user patches globally available

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

On Wed, 18 Apr 2012 22:41:39 +0100
David Leverton <levertond@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Making user patches globally available

[Zac Medico]

On 04/25/2012 09:44 PM, Ryan Hill wrote:
> On Wed, 18 Apr 2012 22:41:39 +0100
> David Leverton <levertond@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]

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

On Wed, 25 Apr 2012 22:03:18 -0700
Zac Medico <zmedico@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Making user patches globally available

[Duncan]

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

[Zac Medico]

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

[Duncan]

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

[Zac Medico]

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

[gentoo-dev] Re: Making user patches globally available

[Duncan]

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

[Zac Medico]

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

[Duncan]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2150 bytes --]

On Fri, 27 Apr 2012 14:15:35 +0000 (UTC)
Duncan <1i5t5.duncan@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: Making user patches globally available

[Zac Medico]

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

[Ulrich Mueller]

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

[Zac Medico]

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

[Alec Warner]

On Fri, Apr 27, 2012 at 11:01 AM, Ulrich Mueller <ulm@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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

On Fri, 27 Apr 2012 20:01:15 +0200
Ulrich Mueller <ulm@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: Making user patches globally available

[Zac Medico]

On 04/27/2012 11:57 AM, Michał Górny wrote:
> On Fri, 27 Apr 2012 20:01:15 +0200
> Ulrich Mueller <ulm@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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

On Fri, 27 Apr 2012 20:01:15 +0200
Ulrich Mueller <ulm@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Making user patches globally available

[Ulrich Mueller]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

On Fri, 27 Apr 2012 21:43:06 +0200
Ulrich Mueller <ulm@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

On Fri, 27 Apr 2012 21:58:24 +0200
Michał Górny <mgorny@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 312 bytes --]

On Fri, 27 Apr 2012 21:12:27 +0100
Ciaran McCreesh <ciaran.mccreesh@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

On Sat, 28 Apr 2012 10:52:07 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Fri, 27 Apr 2012 21:12:27 +0100
> Ciaran McCreesh <ciaran.mccreesh@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)

[Francesco Riosa]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

What's changed from 2006 in version handling?
Il giorno 28/apr/2012 11:39, "Ciaran McCreesh" <
ciaran.mccreesh@googlemail.com> ha scritto:
>
> On Sat, 28 Apr 2012 10:52:07 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Fri, 27 Apr 2012 21:12:27 +0100
> > Ciaran McCreesh <ciaran.mccreesh@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?

[-- Attachment #2: Type: text/html, Size: 1123 bytes --]

Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 230 bytes --]

On Sat, 28 Apr 2012 10:09:01 +0000
Francesco Riosa <vivo75@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Making user patches globally available

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

On Fri, 27 Apr 2012 14:15:35 +0000 (UTC)
Duncan <1i5t5.duncan@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Making user patches globally available

[Zac Medico]

On 04/27/2012 07:27 AM, Ciaran McCreesh wrote:
> On Fri, 27 Apr 2012 14:15:35 +0000 (UTC)
> Duncan <1i5t5.duncan@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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

On Fri, 27 Apr 2012 08:41:35 -0700
Zac Medico <zmedico@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Making user patches globally available

[Zac Medico]

On 04/27/2012 08:45 AM, Ciaran McCreesh wrote:
> On Fri, 27 Apr 2012 08:41:35 -0700
> Zac Medico <zmedico@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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

On Fri, 27 Apr 2012 08:55:49 -0700
Zac Medico <zmedico@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Making user patches globally available

[Zac Medico]

On 04/27/2012 09:00 AM, Ciaran McCreesh wrote:
> On Fri, 27 Apr 2012 08:55:49 -0700
> Zac Medico <zmedico@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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

On Fri, 27 Apr 2012 09:08:06 -0700
Zac Medico <zmedico@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Making user patches globally available

[Zac Medico]

On 04/27/2012 09:11 AM, Ciaran McCreesh wrote:
> On Fri, 27 Apr 2012 09:08:06 -0700
> Zac Medico <zmedico@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

[Nikos Chantziaras]

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.

[gentoo-dev] Re: Making user patches globally available

[Duncan]

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

Re: [gentoo-dev] Re: Making user patches globally available

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 415 bytes --]

On Thu, 26 Apr 2012 06:18:32 +0000 (UTC)
Duncan <1i5t5.duncan@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: Making user patches globally available

[Zac Medico]

On 04/26/2012 11:27 AM, Michał Górny wrote:
> On Thu, 26 Apr 2012 06:18:32 +0000 (UTC)
> Duncan <1i5t5.duncan@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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

On Thu, 26 Apr 2012 11:43:37 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> On 04/26/2012 11:27 AM, Michał Górny wrote:
> > On Thu, 26 Apr 2012 06:18:32 +0000 (UTC)
> > Duncan <1i5t5.duncan@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: Making user patches globally available

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

On Thu, 26 Apr 2012 20:50:02 +0200
Michał Górny <mgorny@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Making user patches globally available

[Patrick Lauer]

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

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.

[gentoo-dev] Re: Making user patches globally available

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]

On Sun, 15 Apr 2012 16:53:04 +0800
Patrick Lauer <patrick@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Making user patches globally available

[Sergei Trofimovich]

[-- Attachment #1: Type: text/plain, Size: 1624 bytes --]

On Sun, 15 Apr 2012 16:53:04 +0800
Patrick Lauer <patrick@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 :) )
> 
> 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.

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?

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.

-- 

  Sergei

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Making user patches globally available

[Duncan]

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 <patrick@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 2>&1 && 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

Re: [gentoo-dev] Making user patches globally available

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1718 bytes --]

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

Well as people have already pointed out, the problem is where to place it:
* before src_prepare is bad because of gentoo-patches
* after src_prepare is bad because of eautoreconf calls in src_prepare

I would even suggest a more radical approach, namely (for an upcoming EAPI) to 
migrate some of the features of base.eclass into the package manager. Applying 
patches is a universal problem which should be handled as central as possible.

As example, (in that future EAPI)
* have patches from the PATCHES array be applied automatically _before_ 
src_prepare (the same way as done currently in base_src_prepare)
* have user patches applied afterwards (either if a FEATURE is set, or 
generally)
* disallow or deprecate at least direct calls to epatch, to ensure ordering
* (and adapt the functions in base and eutils accordingly for that EAPI)

Opinions?

Best, Andreas

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Making user patches globally available

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

On Sun, 15 Apr 2012 13:00:10 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> 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?
> 
> Well as people have already pointed out, the problem is where to
> place it:
> * before src_prepare is bad because of gentoo-patches
> * after src_prepare is bad because of eautoreconf calls in src_prepare
> 
> I would even suggest a more radical approach, namely (for an upcoming
> EAPI) to migrate some of the features of base.eclass into the package
> manager. Applying patches is a universal problem which should be
> handled as central as possible.
> 
> As example, (in that future EAPI)
> * have patches from the PATCHES array be applied automatically
> _before_ src_prepare (the same way as done currently in
> base_src_prepare)

No. EAPIs have overridable phase functions for a reason.

> * disallow or deprecate at least direct calls to epatch, to ensure
> ordering

What if some patches are applied conditionally?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Making user patches globally available

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

On Sun, Apr 15, 2012 at 03:55:58PM +0200, Michał Górny wrote:
> 
> What if some patches are applied conditionally?

imo patches that are applied conditionally should be rewritten so they
can always be applied.

patches that are applied conditionally probably won't get into upsream
most of the time.

Best regards,

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Making user patches globally available

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

On Sun, 15 Apr 2012 17:19:18 -0500
William Hubbs <williamh@gentoo.org> wrote:

> On Sun, Apr 15, 2012 at 03:55:58PM +0200, Michał Górny wrote:
> > 
> > What if some patches are applied conditionally?
> 
> imo patches that are applied conditionally should be rewritten so they
> can always be applied.
> 
> patches that are applied conditionally probably won't get into upsream
> most of the time.

Sometimes patches won't get upstream anyway. Any by making them
conditional, we save users from needless dependencies and complete
autoreconf when it's actually necessary only in a very rare case.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Making user patches globally available

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

On Sun, 15 Apr 2012 02:16:41 -0600
Ryan Hill <dirtyepic@gentoo.org> 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.

That's why we should work on spreading the use of base eclass or one of
similar eclasses rather than reinventing the wheel. On the other hand,
taking into consideration that base.eclass is a pretty roughly shaped
wheel we could consider creating a new base eclass for that.

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

It should have been done there in the first place. But it hasn't,
and this has some advantages. For example, thanks to complete control
over the moment where epatch_user() is called, autotools-utils is able
to smartly do autoreconf when needed. If user patches were forced to be
PM-only feature, there would be no good way of doing that.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Making user patches globally available

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 722 bytes --]

On Sunday 15 April 2012 04:16:41 Ryan Hill wrote:
> 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?

i originally added it to eutils eclass and only called it in some ebuilds 
because people were against lettings users patch anything at all (due to the 
maintenance burden).  the trade off was that maintainers could add it to their 
ebuilds explicitly when they were ok with supporting it.  so that quieted the 
opposition while letting it proliferate throughout the tree.  now we're at the 
point of it being fairly common in the tree, so moving it somewhere more 
central would probably be a good thing.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]