FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 04-24-2012, 08:35 AM
Michał Górny
 
Default epatch_user usage

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.

--
Best regards,
Michał Górny
 
Old 04-26-2012, 04:45 AM
Ryan Hill
 
Default epatch_user usage

On Mon, 23 Apr 2012 22:45:36 -0500
Doug Goldstein <cardoe@gentoo.org> 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?

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?


--
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org
 
Old 04-26-2012, 05:06 AM
Zac Medico
 
Default epatch_user usage

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.
--
Thanks,
Zac
 
Old 05-04-2012, 04:50 AM
Jeroen Roovers
 
Default epatch_user usage

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.


Sincerely,
jer
 
Old 05-04-2012, 08:23 PM
Michał Górny
 
Default 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
 
Old 05-05-2012, 06:01 AM
Ryan Hill
 
Default 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.


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

Thread Tools




All times are GMT. The time now is 05:28 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org