Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 185567 - [Future EAPI] New ebuild function to package sourcecode
Summary: [Future EAPI] New ebuild function to package sourcecode
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: PMS/EAPI
URL: http://news.gmane.org/gmane.linux.gen...
Whiteboard:
Keywords:
Depends on:
Blocks: future-eapi
  Show dependency tree
 
Reported: 2007-07-16 18:33 UTC by Alin Năstac (RETIRED)
Modified: 2014-09-06 21:39 UTC (History)
4 users (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 Alin Năstac (RETIRED) gentoo-dev 2007-07-16 18:33:34 UTC
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).
Comment 1 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2007-07-16 22:27:18 UTC
if it doesn't concern users, why EAPI=1?
Comment 2 Brian Harring gentoo-dev 2007-07-16 23:20:13 UTC
Why isn't this getting hashed out on the ml?  Seriously, take it there- folks semi agree, bring it back.
Comment 3 SpanKY gentoo-dev 2007-07-17 04:18:22 UTC
pkg_create() is a poor name (too confusing with creating a binary package)

but yes, please start a thread on gentoo-dev first
Comment 4 Alin Năstac (RETIRED) gentoo-dev 2007-07-17 10:04:15 UTC
How about src_create?
Comment 5 Marius Mauch (RETIRED) gentoo-dev 2007-07-17 10:40:06 UTC
More like src_package or src_makedist, as the function wouldn't create anything new, just repackage existing content.
Comment 6 SpanKY gentoo-dev 2007-07-17 17:15:30 UTC
src_makedist is best so far i think
Comment 7 SpanKY gentoo-dev 2007-07-24 18:25:49 UTC
portage guys: people like this on the mailing list, any chance we can get it tossed in ?
Comment 8 Zac Medico gentoo-dev 2007-07-24 18:54:02 UTC
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?
Comment 9 Ciaran McCreesh 2007-07-24 18:56:33 UTC
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.
Comment 10 Zac Medico gentoo-dev 2007-07-24 18:57:26 UTC
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?
Comment 11 Ciaran McCreesh 2007-07-24 18:58:22 UTC
Mmm. In fact, why not create a new class of function? Call it maint_ or something...
Comment 12 SpanKY gentoo-dev 2007-07-24 19:01:21 UTC
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 ...
Comment 13 Brian Harring gentoo-dev 2007-07-25 10:50:37 UTC
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).
Comment 14 SpanKY gentoo-dev 2007-08-02 22:48:28 UTC
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 ...
Comment 15 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-08-30 10:55:49 UTC
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.
Comment 16 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-09-06 21:39:31 UTC
The issue doesn't really concern users, no reply for over a year, assuming interest was lost.