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-18-2012, 07:47 PM
Michał Górny
 
Default Making user patches globally available

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

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....
 
Old 04-23-2012, 05:04 AM
Steven J Long
 
Default Making user patches globally available

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 ;-)
 
Old 04-23-2012, 05:56 AM
Zac Medico
 
Default Making user patches globally available

On 04/22/2012 10:04 PM, Steven J Long wrote:
> It seems there's two major cases, with autotools or without. In either case,
> epatch_user should be called after Gentoo patches have been applied.
>
> Why not make epatch_user set a variable to indicate that patches have been
> applied, and only apply the patches on the first call?
>
> Then eautoreconf could call it before calling autoconf (and the ebuild
> wouldn't need to worry about it.) And any custom src_prepare function could
> call it when needed, if it needed to be done during the phase, and not
> after.
>
> After src_prepare, the PM could just call it unconditionally, since it will
> not apply the patches again, if it's already been called by the ebuild.
>
> Does that make sense?

Yeah, sounds roughly equivalent to Ciaran's suggested
"apply_user_patches_here" approach [1], except that Ciaran suggested to
make it an error if src_prepare doesn't call apply_user_patches_here (so
people don't forget to call it when they should).

[1]
http://archives.gentoo.org/gentoo-dev/msg_c228be85e0c4e577ad194e6004d59062.xml
--
Thanks,
Zac
 
Old 04-26-2012, 04:44 AM
Ryan Hill
 
Default Making user patches globally available

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
 
Old 04-26-2012, 05:03 AM
Zac Medico
 
Default Making user patches globally available

On 04/25/2012 09:44 PM, Ryan Hill wrote:
> On Wed, 18 Apr 2012 22:41:39 +0100
> David Leverton <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
 
Old 04-26-2012, 06:09 AM
Ryan Hill
 
Default Making user patches globally available

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
 
Old 04-26-2012, 06:18 AM
Duncan
 
Default Making user patches globally available

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

On 04/25/2012 11:18 PM, Duncan wrote:
> IOW, let's quit letting the perfect be the enemy of the good, and just
> get on with it, already.

If that means settling on something that's fragile and prone to lots of
bug reports, then it's not really practical, because it wastes peoples
time (and time is our most valuable resource).
--
Thanks,
Zac
 
Old 04-26-2012, 09:55 AM
Duncan
 
Default Making user patches globally available

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
 

Thread Tools




All times are GMT. The time now is 10:51 PM.

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