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. |