Summary: | [Future EAPI] New ebuild function to package sourcecode | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Alin Năstac (RETIRED) <mrness> |
Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | dev-portage, esigra, gengor, nerdboy |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://news.gmane.org/gmane.linux.gentoo.devel/cutoff=50623 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 174380 |
Description
Alin Năstac (RETIRED)
2007-07-16 18:33:34 UTC
if it doesn't concern users, why EAPI=1? Why isn't this getting hashed out on the ml? Seriously, take it there- folks semi agree, bring it back. pkg_create() is a poor name (too confusing with creating a binary package) but yes, please start a thread on gentoo-dev first How about src_create? More like src_package or src_makedist, as the function wouldn't create anything new, just repackage existing content. src_makedist is best so far i think portage guys: people like this on the mailing list, any chance we can get it tossed in ? Okay, so we have a new phase called src_makedist(). Does this phase depend on any other phases or does it just need the usual ${WORKDIR} and ${T} directories created? Should the initial starting directory be ${WORKDIR}? Is anything else required? Does WORKDIR even make sense here? It's neither a pkg_ nor a src_ function in the conventional sense, so neither set of variables is entirely sane. Oh, and what about ${DISTDIR}? Is the phase supposed to be able to put it's created distfile(s) there? If not, where should it put them? Mmm. In fact, why not create a new class of function? Call it maint_ or something... i thought about automatically moving to $DISTDIR, but perhaps it'd be better if the ebuild simply did something like: einfo "The package ${PWD}/${P}.tar.bz2 is ready for you" due to the nature, just rolling with ${T} alone should be enough ... Offhand, a glep might be wise here (document the form of it, alternatives proposed but decided against, etc); gleps pretty much exist for this, presuming they're still used in any form. Meanwhile, might want to take a look at how this will actually look in an ebuild- ebuilds would wind up having to inherit svn,cvs, etc for a single phase very rarely used. Said inherits add some extra phases in that may not be desirable- so would look for ways to make it saner/simpler to use. Aside from that, might want to eye the potential for generating src snapshots for the live ebuilds (mildly crazy, but who knows). thinking about it, if we did have a new "maintainer" phase, we could move a ton of the QA checks out of post src_install and into this phase ... maintainers could then invoke it by hand when testing new ebuilds and move much out of the visible scope for users we'd have a general set of checks and if the ebuild wanted to also implement its own, those would be run after the general ones ... Was anything specific decided here? I don't see anyone mentioning which other phases this special thing would require run first nor anything really specific. And I'm not sure if it'd be this easy. One person wants a function to repackage sources, other would want one to package compiled stuff for *-bin packages. I'm not sure if we should focus on just one of those cases, and I'm not sure if we should pollute ebuilds with random maintenance cruft. The issue doesn't really concern users, no reply for over a year, assuming interest was lost. |