| 1 |
Jan Kundrát wrote: |
| 2 |
> Alin Năstac wrote: |
| 3 |
> |
| 4 |
>> The upstream doesn't offer a source tarball, so I need to construct |
| 5 |
>> it myself from their svn repository. |
| 6 |
>> |
| 7 |
> |
| 8 |
> If you're creating a live ebuild, there are already existing eclasses |
| 9 |
> that works from the user's POV. |
| 10 |
> |
| 11 |
I'm not speaking about live ebuilds, only about building a source |
| 12 |
tarball for a specific version where upstream doesn't offer such thing. |
| 13 |
> If your aim is to create an ebuild for a specific version, you might as |
| 14 |
> well checkout stuff yourself and let Gentoo mirror the generated tarball |
| 15 |
> (your mail doesn't talk about RESTRICT=fetch). If you let Gentoo mirror |
| 16 |
> the tarball, users are likely to be happier because they'll get the file |
| 17 |
> faster and in a more reliable way. |
| 18 |
> |
| 19 |
What I want is a function that creates the source tarball, based on |
| 20 |
whatever developer needs for that (the most usual case is a tag export |
| 21 |
from a svn/cvs repository). The tarball will be placed on Gentoo mirrors |
| 22 |
at the end (users will not run this new function, only the maintainer). |
| 23 |
See app-mobilephone/bitpim ebuild example, it will speak for itself. |
| 24 |
|
| 25 |
This can be solved also through an external script, but IMO this |
| 26 |
solution is ugly. Ebuilds should contain whatever is needed for their |
| 27 |
maintenance. |
Archives