I need a special fuction that helps me create the tarball, something that would allow me to create the package by running ebuild $P.ebuild create pkg_create() will be executed only in the context of the above command and will not concern users in any way. The package where I need it is app-mobilephone/bitpim. The upstream doesn't offer a source tarball, so I need to construct it myself from their svn repository. Up till recently, I used some hackery in pkg_setup() to create it (see the ebuild), but now "ebuild $P.ebuild setup" verify the digest before running pkg_setup(). Using a function in the ebuild has the advantage of being easily maintainable by anyone (not just me).
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.
