Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 463692 - [Future EAPI] Provide PATCHES array support in default phase of src_prepare
Summary: [Future EAPI] Provide PATCHES array support in default phase of src_prepare
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
URL:
Whiteboard: in-eapi-6
Keywords:
Depends on: 463768
Blocks: future-eapi
  Show dependency tree
 
Reported: 2013-03-29 09:18 UTC by Tomáš Chvátal (RETIRED)
Modified: 2015-11-08 21:49 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tomáš Chvátal (RETIRED) gentoo-dev 2013-03-29 09:18:29 UTC 
As per summary this is the only thing left in base eclass that eapi5 can't do.
So prefferably with next gen we should be just able to use it everywhere.

Also some developers refuse to use the array even if they inherit the base eclass because it is not in eapi, so it would be nice to have it and used everywhere.
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-03-29 09:26:38 UTC 
You've got my +1. That was the thing I forgot about!
Comment 2 Tomáš Chvátal (RETIRED) gentoo-dev 2013-03-29 09:31:06 UTC 
Also another bit wrt this bug might be support for epatch_user, but that thing must be redone a bit.

If it would be enabled on "all packages" then it must be obvious from starters if the patches are provided by user or by us. Something in emerge.log about those with huge "!!!! USER_PATCH: blabla-i-screwed-my-build.patch" could be enough... :-)
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-03-29 09:47:58 UTC 
(In reply to comment #2)
> Also another bit wrt this bug might be support for epatch_user, but that
> thing must be redone a bit.
> 
> If it would be enabled on "all packages" then it must be obvious from
> starters if the patches are provided by user or by us. Something in
> emerge.log about those with huge "!!!! USER_PATCH:
> blabla-i-screwed-my-build.patch" could be enough... :-)

Well, I'd say it's pretty obvious right now that the code would have to be quite verbose.

Hmm but we don't have epatch in the EAPI. We should have a bug for that as well. I don't really want EAPI once again not to provide the tools it uses.
Comment 4 Julian Ospald 2013-03-29 17:58:08 UTC 
epatch is not in PMS, so how does this compute?
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-03-29 17:59:32 UTC 
(In reply to comment #4)
> epatch is not in PMS, so how does this compute?

I see two possibilities:

a) we add epatch ;),

b) we use something like 'patch -p1' and end the epatch mess.
Comment 6 Julian Ospald 2013-03-29 18:00:09 UTC 
I am for a)
Comment 7 Ulrich Müller gentoo-dev 2013-08-18 12:30:03 UTC 
Should both an array and a whitespace separated list be supported, as in base.eclass? That would also be consistent with the DOCS variable.
Comment 8 Tomáš Chvátal (RETIRED) gentoo-dev 2013-08-18 15:13:00 UTC 
(In reply to Ulrich Müller from comment #7)
> Should both an array and a whitespace separated list be supported, as in
> base.eclass? That would also be consistent with the DOCS variable.

Indiferent, whatever is inlined with rest of the variables would be best.
OTOH question is how many packages do we have that still use non-array patches if it is really really needed.
Comment 9 Ulrich Müller gentoo-dev 2014-06-16 10:47:17 UTC 
We support whitespace separated lists for all other package manager variables, so I think for reasons of consistency we should support them also for PATCHES. Also it is trivial to implement (simply copy the test for the DOCS variable from src_install).