Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

Making user patches globally available

 

 

First page Previous page 1 2 3 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


dirtyepic at gentoo

Apr 15, 2012, 1:16 AM

Post #1 of 60 (635 views)
Permalink
Making user patches globally available

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
Attachments: signature.asc (0.19 KB)


zmedico at gentoo

Apr 15, 2012, 1:35 AM

Post #2 of 60 (627 views)
Permalink
Re: Making user patches globally available [In reply to]

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


patrick at gentoo

Apr 15, 2012, 1:53 AM

Post #3 of 60 (624 views)
Permalink
Re: Making user patches globally available [In reply to]

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.


dirtyepic at gentoo

Apr 15, 2012, 2:03 AM

Post #4 of 60 (626 views)
Permalink
Re: Making user patches globally available [In reply to]

On Sun, 15 Apr 2012 01:35:40 -0700
Zac Medico <zmedico [at] gentoo> 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
Attachments: signature.asc (0.19 KB)


zmedico at gentoo

Apr 15, 2012, 2:12 AM

Post #5 of 60 (626 views)
Permalink
Re: Re: Making user patches globally available [In reply to]

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


dirtyepic at gentoo

Apr 15, 2012, 2:18 AM

Post #6 of 60 (627 views)
Permalink
Re: Making user patches globally available [In reply to]

On Sun, 15 Apr 2012 16:53:04 +0800
Patrick Lauer <patrick [at] gentoo> 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
Attachments: signature.asc (0.19 KB)


slyfox at gentoo

Apr 15, 2012, 2:25 AM

Post #7 of 60 (627 views)
Permalink
Re: Making user patches globally available [In reply to]

On Sun, 15 Apr 2012 16:53:04 +0800
Patrick Lauer <patrick [at] gentoo> 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
Attachments: signature.asc (0.19 KB)


dilfridge at gentoo

Apr 15, 2012, 4:00 AM

Post #8 of 60 (627 views)
Permalink
Re: Making user patches globally available [In reply to]

> 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 [at] gentoo
http://www.akhuettel.de/
Attachments: signature.asc (0.19 KB)


axs at gentoo

Apr 15, 2012, 6:46 AM

Post #9 of 60 (625 views)
Permalink
Re: Re: Making user patches globally available [In reply to]

On 2012-04-15, at 5:03 AM, Ryan Hill <dirtyepic [at] gentoo> wrote:

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


mgorny at gentoo

Apr 15, 2012, 6:55 AM

Post #10 of 60 (629 views)
Permalink
Re: Making user patches globally available [In reply to]

On Sun, 15 Apr 2012 13:00:10 +0200
"Andreas K. Huettel" <dilfridge [at] gentoo> 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
Attachments: signature.asc (0.31 KB)


mgorny at gentoo

Apr 15, 2012, 7:01 AM

Post #11 of 60 (624 views)
Permalink
Re: Making user patches globally available [In reply to]

On Sun, 15 Apr 2012 02:16:41 -0600
Ryan Hill <dirtyepic [at] gentoo> 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
Attachments: signature.asc (0.31 KB)


vapier at gentoo

Apr 15, 2012, 9:25 AM

Post #12 of 60 (613 views)
Permalink
Re: Making user patches globally available [In reply to]

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
Attachments: signature.asc (0.82 KB)


williamh at gentoo

Apr 15, 2012, 3:19 PM

Post #13 of 60 (610 views)
Permalink
Re: Making user patches globally available [In reply to]

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


1i5t5.duncan at cox

Apr 15, 2012, 4:34 PM

Post #14 of 60 (608 views)
Permalink
Re: Making user patches globally available [In reply to]

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 [at] gentoo>
> 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


mgorny at gentoo

Apr 16, 2012, 1:12 AM

Post #15 of 60 (609 views)
Permalink
Re: Making user patches globally available [In reply to]

On Sun, 15 Apr 2012 17:19:18 -0500
William Hubbs <williamh [at] gentoo> 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
Attachments: signature.asc (0.31 KB)


jer at gentoo

Apr 18, 2012, 9:59 AM

Post #16 of 60 (592 views)
Permalink
Re: Making user patches globally available [In reply to]

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


vapier at gentoo

Apr 18, 2012, 10:39 AM

Post #17 of 60 (592 views)
Permalink
Re: Making user patches globally available [In reply to]

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
Attachments: signature.asc (0.82 KB)


ciaran.mccreesh at googlemail

Apr 18, 2012, 10:41 AM

Post #18 of 60 (592 views)
Permalink
Re: Making user patches globally available [In reply to]

On Wed, 18 Apr 2012 13:39:59 -0400
Mike Frysinger <vapier [at] gentoo> 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
Attachments: signature.asc (0.19 KB)


zmedico at gentoo

Apr 18, 2012, 11:20 AM

Post #19 of 60 (592 views)
Permalink
Re: Making user patches globally available [In reply to]

On 04/18/2012 10:41 AM, Ciaran McCreesh wrote:
> On Wed, 18 Apr 2012 13:39:59 -0400
> Mike Frysinger<vapier [at] gentoo> 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


levertond at googlemail

Apr 18, 2012, 11:34 AM

Post #20 of 60 (594 views)
Permalink
Re: Making user patches globally available [In reply to]

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.


zmedico at gentoo

Apr 18, 2012, 12:41 PM

Post #21 of 60 (593 views)
Permalink
Re: Making user patches globally available [In reply to]

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


mgorny at gentoo

Apr 18, 2012, 12:47 PM

Post #22 of 60 (595 views)
Permalink
Re: Making user patches globally available [In reply to]

On Wed, 18 Apr 2012 12:41:32 -0700
Zac Medico <zmedico [at] gentoo> 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
Attachments: signature.asc (0.31 KB)


levertond at googlemail

Apr 18, 2012, 2:41 PM

Post #23 of 60 (593 views)
Permalink
Re: Making user patches globally available [In reply to]

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


slong at rathaus

Apr 22, 2012, 10:04 PM

Post #24 of 60 (550 views)
Permalink
Re: Making user patches globally available [In reply to]

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


zmedico at gentoo

Apr 22, 2012, 10:56 PM

Post #25 of 60 (549 views)
Permalink
Re: Re: Making user patches globally available [In reply to]

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

First page Previous page 1 2 3 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.