On Tue, 24 Apr 2012 00:25:56 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> On Tuesday 24 April 2012 00:15:45 Michał Górny wrote:
> > On Tue, 24 Apr 2012 00:10:30 -0400 Mike Frysinger wrote:
> > > On Monday 23 April 2012 23:45:36 Doug Goldstein wrote:
> > > > So I've just had one reservation when using epatch_user for
> > > > allowing users to apply patches. And that's figuring out when
> > > > to run eautoreconf. I don't necessarily want to run it
> > > > unconditionally but sometimes users have patches which touch
> > > > autoconf files but my existing patch set doesn't so I'm not
> > > > calling eautoreconf. Does anyone have a suggested way to handle
> > > > this?
> > >
> > > just always call it when the user applies patches. i don't see a
> > > big deal. epatch_user && eautoreconf
> >
> > No configure.{ac,in} present!
>
> if the package doesn't have configure.{ac,in} files, then why would
> he be talking about eautoreconf ?
Ah, so we're talking per-package now. Sorry, thought it would be forced
everywhere.
> So I've just had one reservation when using epatch_user for allowing
> users to apply patches. And that's figuring out when to run
> eautoreconf. I don't necessarily want to run it unconditionally but
> sometimes users have patches which touch autoconf files but my
> existing patch set doesn't so I'm not calling eautoreconf. Does anyone
> have a suggested way to handle this?
It's kind of hacky, but what about having the user `touch eautoreconf` in the
patch directory? Or a file named "post_patch" containing a list of commands
to run.
Could we detect user patches touching autoconf files somehow, maybe by
hashing them beforehand or grepping patch headers, or would this be too error
prone?
> On 04/25/2012 09:45 PM, Ryan Hill wrote:
> > Could we detect user patches touching autoconf files somehow, maybe
> > by hashing them beforehand
>
> There's an implementation of that inside autotools-utils_src_prepare.
There's all kinds of reasons to not use autotools-utils.eclass.
I wouldn't want to see another python.eclass bullying around the tree.
Sincerely,
jer
05-04-2012, 08:23 PM
Michał Górny
epatch_user usage
On Fri, 4 May 2012 06:50:12 +0200
Jeroen Roovers <jer@gentoo.org> wrote:
> On Wed, 25 Apr 2012 22:06:08 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>
> > On 04/25/2012 09:45 PM, Ryan Hill wrote:
> > > Could we detect user patches touching autoconf files somehow,
> > > maybe by hashing them beforehand
> >
> > There's an implementation of that inside
> > autotools-utils_src_prepare.
>
> There's all kinds of reasons to not use autotools-utils.eclass.
> I wouldn't want to see another python.eclass bullying around the tree.
504 autotools-utils.eclass
3186 python.eclass
Do you have any real arguments?
--
Best regards,
Michał Górny
05-05-2012, 06:01 AM
Ryan Hill
epatch_user usage
On Fri, 4 May 2012 22:23:31 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > There's all kinds of reasons to not use autotools-utils.eclass.
> > I wouldn't want to see another python.eclass bullying around the tree.
>
> 504 autotools-utils.eclass
> 3186 python.eclass
>
> Do you have any real arguments?
I think his point was that like the python eclass, autotools-utils requires
you to give up a lot of control over your ebuild to it. It started out as a
simple way to standardize common autotools-related tasks. Then it began
growing and adding a bunch of stuff that, while I'm sure was useful to some,
I didn't need or had to handle differently. Then these features started
becoming interdependent and I started getting bug reports about how my
packages were misusing the eclass because I didn't want to cede full control
over to its phase functions.
Don't get me wrong, I understand the reasons why it has to work the way it
does and I'm sure most people are fine with it. But I'm wary about giving
that much power over to an eclass I can't control. I hate exported phase
functions in general though, so read into that what you will.
epatch_user usage
