| 1 |
On Tuesday 17 July 2007, Marius Mauch wrote: |
| 2 |
> Alin Năstac <mrness@g.o> wrote: |
| 3 |
> > I was asked to discuss here a portage enhancement proposed by me [1]. |
| 4 |
> > |
| 5 |
> > Basically I need a pkg_create() that will be executed only in the |
| 6 |
> > context of the upcoming "ebuild ${PF}.ebuild create" command. |
| 7 |
> > |
| 8 |
> > The package where I need it is app-mobilephone/bitpim. The upstream |
| 9 |
> > doesn't offer a source tarball, so I need to construct it myself from |
| 10 |
> > their svn repository. Up till recently, I used some hackery in |
| 11 |
> > pkg_setup() to create it |
| 12 |
> > (see the ebuild), but now "ebuild $PF.ebuild setup" verify the digest |
| 13 |
> > before running pkg_setup(). |
| 14 |
> > |
| 15 |
> > [1] http://bugs.gentoo.org/show_bug.cgi?id=185567 |
| 16 |
> |
| 17 |
> Two questions: |
| 18 |
> - are there more packages that could benefit from this? |
| 19 |
> - is there a particular reason this has to be integrated into the |
| 20 |
> ebuild and should not be handled by an ordinary script? |
| 21 |
|
| 22 |
i'll have to ponder for a while, but in the past, i could have made use of |
| 23 |
something like this ... lacking it, i had hand written scripts to do it for |
| 24 |
me. every case where i needed this though it was a similar situation -- |
| 25 |
upstream did not provide a release, but did provide SCM access. actually, |
| 26 |
netpbm is another example of where this could be utilized as they only tag |
| 27 |
releases in their svn, not roll tarballs ... |
| 28 |
-mike |
Archives