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 User

 
 
LinkBack Thread Tools
 
Old 09-12-2011, 01:41 PM
justin
 
Default /etc/portage/patches/

On 9/12/11 3:21 PM, Nikos Chantziaras wrote:
> Some packages can apply patches from /etc/portage/patches/, other don't.
> Why don't all packages do that? Is there a way to make all packages
> use /etc/portage/patches?
>
>

It a specific function which needs to be added to the ebuild by the
writer. To make all ebuilds respect user patches (where there are pros
and cons) the package manager must handle that function internally.

justin
 
Old 09-12-2011, 01:51 PM
Nikos Chantziaras
 
Default /etc/portage/patches/

On 09/12/2011 04:41 PM, justin wrote:

On 9/12/11 3:21 PM, Nikos Chantziaras wrote:

Some packages can apply patches from /etc/portage/patches/, other don't.
Why don't all packages do that? Is there a way to make all packages
use /etc/portage/patches?




It a specific function which needs to be added to the ebuild by the
writer. To make all ebuilds respect user patches (where there are pros
and cons) the package manager must handle that function internally.


This sucks. Is there anything I can in /etc/portage/env to make all
ebuilds call epatch_user() ?
 
Old 09-12-2011, 02:14 PM
justin
 
Default /etc/portage/patches/

A hacky trick would be to implement it yourself by adding the
appropriate function to post_src_unpack of post_src_prepare in
/etc/portage/bashrc.

Nut this is out of warranty, but should work




On 9/12/11 3:51 PM, Nikos Chantziaras wrote:
> On 09/12/2011 04:41 PM, justin wrote:
>> On 9/12/11 3:21 PM, Nikos Chantziaras wrote:
>>> Some packages can apply patches from /etc/portage/patches/, other don't.
>>> Why don't all packages do that? Is there a way to make all packages
>>> use /etc/portage/patches?
>>>
>>>
>>
>> It a specific function which needs to be added to the ebuild by the
>> writer. To make all ebuilds respect user patches (where there are pros
>> and cons) the package manager must handle that function internally.
>
> This sucks. Is there anything I can in /etc/portage/env to make all
> ebuilds call epatch_user() ?
>
>
 
Old 09-12-2011, 02:42 PM
Nikos Chantziaras
 
Default /etc/portage/patches/

Thanks! A bashrc with the following in it seems to work here just fine:

post_src_unpack() {
epatch_user
}

Also, the epatch_user() docs mention that it's safe to call epatch_user
multiple times, so I support no breakages should be expected with
ebuilds and eclasses that call this function on their own.



On 09/12/2011 05:14 PM, justin wrote:

A hacky trick would be to implement it yourself by adding the
appropriate function to post_src_unpack of post_src_prepare in
/etc/portage/bashrc.

Nut this is out of warranty, but should work

On 9/12/11 3:51 PM, Nikos Chantziaras wrote:

On 09/12/2011 04:41 PM, justin wrote:

On 9/12/11 3:21 PM, Nikos Chantziaras wrote:

Some packages can apply patches from /etc/portage/patches/, other don't.
Why don't all packages do that? Is there a way to make all packages
use /etc/portage/patches?


It a specific function which needs to be added to the ebuild by the
writer. To make all ebuilds respect user patches (where there are pros
and cons) the package manager must handle that function internally.


This sucks. Is there anything I can in /etc/portage/env to make all
ebuilds call epatch_user() ?
 
Old 09-12-2011, 03:02 PM
Nikos Chantziaras
 
Default /etc/portage/patches/

On 09/12/2011 05:42 PM, Nikos Chantziaras wrote:

Thanks! A bashrc with the following in it seems to work here just fine:

post_src_unpack() {
epatch_user
}


In case anyone else is trying this, the above should be:

post_src_unpack() {
cd "${S}"
epatch_user
}
 
Old 09-18-2011, 04:42 PM
Nikos Chantziaras
 
Default /etc/portage/patches/

On 09/12/2011 05:42 PM, Nikos Chantziaras wrote:

Thanks! A bashrc with the following in it seems to work here just fine:

post_src_unpack() {
epatch_user
}

Also, the epatch_user() docs mention that it's safe to call epatch_user
multiple times, so I support no breakages should be expected with
ebuilds and eclasses that call this function on their own.


I came across some ebuilds that result in:

* QA Notice: command not found:
*
* /etc/portage/bashrc: line 3: epatch_user: command not found

How do I solve that one?
 
Old 09-18-2011, 08:27 PM
walt
 
Default /etc/portage/patches/

On 09/18/2011 09:42 AM, Nikos Chantziaras wrote:
> On 09/12/2011 05:42 PM, Nikos Chantziaras wrote:
>> Thanks! A bashrc with the following in it seems to work here just fine:
>>
>> post_src_unpack() {
>> epatch_user
>> }
>>
>> Also, the epatch_user() docs mention that it's safe to call epatch_user
>> multiple times, so I support no breakages should be expected with
>> ebuilds and eclasses that call this function on their own.
>
> I came across some ebuilds that result in:
>
> * QA Notice: command not found:
> *
> * /etc/portage/bashrc: line 3: epatch_user: command not found
>
> How do I solve that one?

The epatch_user() is defined in /usr/portage/ebuild/eutils.eclass, so
I would guess that the ebuild would need the line "inherit eutils", or
at least inherit some other eclass that inherits it.
 
Old 09-18-2011, 08:37 PM
Nikos Chantziaras
 
Default /etc/portage/patches/

On 09/18/2011 11:27 PM, walt wrote:

On 09/18/2011 09:42 AM, Nikos Chantziaras wrote:

On 09/12/2011 05:42 PM, Nikos Chantziaras wrote:

Thanks! A bashrc with the following in it seems to work here just fine:

post_src_unpack() {
epatch_user
}

Also, the epatch_user() docs mention that it's safe to call epatch_user
multiple times, so I support no breakages should be expected with
ebuilds and eclasses that call this function on their own.


I came across some ebuilds that result in:

* QA Notice: command not found:
*
* /etc/portage/bashrc: line 3: epatch_user: command not found

How do I solve that one?


The epatch_user() is defined in /usr/portage/ebuild/eutils.eclass, so
I would guess that the ebuild would need the line "inherit eutils", or
at least inherit some other eclass that inherits it.


The whole point is to not touch the ebuild but utilize bashrc instead :-/
 
Old 09-18-2011, 08:50 PM
Alex Schuster
 
Default /etc/portage/patches/

Nikos Chantziaras writes:

> On 09/18/2011 11:27 PM, walt wrote:
> > On 09/18/2011 09:42 AM, Nikos Chantziaras wrote:

> >> I came across some ebuilds that result in:
> >>
> >> * QA Notice: command not found:
> >> *
> >> * /etc/portage/bashrc: line 3: epatch_user: command not found
> >>
> >> How do I solve that one?
> >
> > The epatch_user() is defined in /usr/portage/ebuild/eutils.eclass, so
> > I would guess that the ebuild would need the line "inherit eutils", or
> > at least inherit some other eclass that inherits it.
>
> The whole point is to not touch the ebuild but utilize bashrc
> instead :-/

Do these ebuilds also need to apply the patches, or do you just want to
get rid of the error message?

Wonko
 
Old 09-18-2011, 08:59 PM
Nikos Chantziaras
 
Default /etc/portage/patches/

On 09/18/2011 11:50 PM, Alex Schuster wrote:

Nikos Chantziaras writes:


On 09/18/2011 11:27 PM, walt wrote:

On 09/18/2011 09:42 AM, Nikos Chantziaras wrote:



I came across some ebuilds that result in:

* QA Notice: command not found:
*
* /etc/portage/bashrc: line 3: epatch_user: command not found

How do I solve that one?


The epatch_user() is defined in /usr/portage/ebuild/eutils.eclass, so
I would guess that the ebuild would need the line "inherit eutils", or
at least inherit some other eclass that inherits it.


The whole point is to not touch the ebuild but utilize bashrc
instead :-/


Do these ebuilds also need to apply the patches, or do you just want to
get rid of the error message?


It's just the error message. Which means this isn't an issue for now.
It will become one if one of them will need patches though.


Too bad that I can't put "inherit eutils" in bashrc though. But even I
could, inheriting an eclass twice would probably not work to begin with.
 

Thread Tools




All times are GMT. The time now is 05:31 AM.

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