Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 351103 - [Future EAPI] Move default phase functions into the repo
Summary: [Future EAPI] Move default phase functions into the repo
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: PMS/EAPI
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: future-eapi
  Show dependency tree
 
Reported: 2011-01-08 10:42 UTC by Michał Górny
Modified: 2013-08-30 11:28 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-01-08 10:42:38 UTC
Right now, PMS describes what default phase functions are supposed to do, or even provides a code snippets for them. The same (or similar) bash code is repeated in various PMs, and possibly partially overriden or reused by eclasses.

Maybe it's a good idea to provide default phase functions in an eclass or similar file, contained within the gx86 repo. PMs would inherit this eclass (say, default.eclass to match phase function names) implicitly and grab default phase functions there.

The advantage of that solution would be reusing code and making it simpler to control its behavior (for example, right now Portage forces 'emake -j1' in src_test()).

I guess some of the default EAPI functions could be moved to that eclass too.
Comment 1 Ciaran McCreesh 2011-01-08 10:46:42 UTC
So when you change src_test, you break every single package using the newer EAPI? Doesn't this idea defeat the entire point of having EAPIs?
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-01-08 10:50:36 UTC
(In reply to comment #1)
> So when you change src_test, you break every single package using the newer
> EAPI? Doesn't this idea defeat the entire point of having EAPIs?

I meant having these implementations EAPI-specific, like eclasses currently do.
Comment 3 Ciaran McCreesh 2011-01-08 10:53:21 UTC
Then why not just have them as part of the package managers? The code reuse argument doesn't fly, since it's useful to be able to make use of package manager internal things to implement functions and helpers. And if you're sticking to EAPIs, you don't gain anything by making the changes in the tree as opposed to in the EAPI definition.
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-08-30 11:28:13 UTC
I withdraw this since people don't like it.