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-15-2012, 04:25 PM
Mike Frysinger
 
Default Making user patches globally available

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
 
Old 04-15-2012, 10:19 PM
William Hubbs
 
Default Making user patches globally available

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
 
Old 04-15-2012, 11:34 PM
Duncan
 
Default Making user patches globally available

Sergei Trofimovich posted on Sun, 15 Apr 2012 12:25:12 +0300 as excerpted:

> On Sun, 15 Apr 2012 16:53:04 +0800 Patrick Lauer <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
 
Old 04-16-2012, 08:12 AM
Michał Górny
 
Default Making user patches globally available

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
 
Old 04-18-2012, 04:59 PM
Jeroen Roovers
 
Default Making user patches globally available

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
 
Old 04-18-2012, 05:39 PM
Mike Frysinger
 
Default Making user patches globally available

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
 
Old 04-18-2012, 05:41 PM
Ciaran McCreesh
 
Default Making user patches globally available

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
 
Old 04-18-2012, 06:20 PM
Zac Medico
 
Default Making user patches globally available

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
 
Old 04-18-2012, 06:34 PM
David Leverton
 
Default Making user patches globally available

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.
 
Old 04-18-2012, 07:41 PM
Zac Medico
 
Default Making user patches globally available

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
 

Thread Tools




All times are GMT. The time now is 10:45 AM.

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