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, 08:35 AM
Zac Medico
 
Default Making user patches globally available

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
 
Old 04-15-2012, 08:53 AM
Patrick Lauer
 
Default Making user patches globally available

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.
 
Old 04-15-2012, 09:03 AM
Ryan Hill
 
Default Making user patches globally available

On Sun, 15 Apr 2012 01:35:40 -0700
Zac Medico <zmedico@gentoo.org> 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
 
Old 04-15-2012, 09:12 AM
Zac Medico
 
Default Making user patches globally available

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
 
Old 04-15-2012, 09:18 AM
Ryan Hill
 
Default Making user patches globally available

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?
> >
>
> 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
 
Old 04-15-2012, 09:25 AM
Sergei Trofimovich
 
Default Making user patches globally available

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?
> >
>
> 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
 
Old 04-15-2012, 11:00 AM
"Andreas K. Huettel"
 
Default 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?

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@gentoo.org
http://www.akhuettel.de/
 
Old 04-15-2012, 01:46 PM
Ian Stakenvicius
 
Default Making user patches globally available

On 2012-04-15, at 5:03 AM, Ryan Hill <dirtyepic@gentoo.org> wrote:

> On Sun, 15 Apr 2012 01:35:40 -0700
> Zac Medico <zmedico@gentoo.org> 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 ....
 
Old 04-15-2012, 01:55 PM
Michał Górny
 
Default Making user patches globally available

On Sun, 15 Apr 2012 13:00:10 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> 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
 
Old 04-15-2012, 02:01 PM
Michał Górny
 
Default Making user patches globally available

On Sun, 15 Apr 2012 02:16:41 -0600
Ryan Hill <dirtyepic@gentoo.org> 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
 

Thread Tools




All times are GMT. The time now is 12:30 AM.

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