| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 28/08/13 01:39 PM, Michał Górny wrote: |
| 5 |
> The question would be: do you feel like we should really provide a |
| 6 |
> verbatim clone of upstream's repository? Or should we focus on the |
| 7 |
> eclass' main goal, that is fetching the remote sources in the most |
| 8 |
> bandwith and space-efficient manner? |
| 9 |
|
| 10 |
|
| 11 |
+1 on the second one -- eclasses are first and foremost to support |
| 12 |
ebuilds, and unless ebuilds need access to multiple branches at the |
| 13 |
same time or some other rather odd and non-straight-forward git trick |
| 14 |
that would require a full clone, all we should worry about doing is |
| 15 |
providing a way to get that shallow clone of only that code snapshot |
| 16 |
that the ebuild needs to build. |
| 17 |
|
| 18 |
|
| 19 |
As a bit of a tangent, if an end-user has their own local clone of a |
| 20 |
repository and uses ${PN}_LIVE_REPO to point to it (or if they have a |
| 21 |
custom out-of-tree ebuild that only has a local URI), it might be nice |
| 22 |
to detect that and skip the fetch so that a checkout can be done from |
| 23 |
it directly into ${S} rather than doing the extra copy... |
| 24 |
|
| 25 |
|
| 26 |
-----BEGIN PGP SIGNATURE----- |
| 27 |
Version: GnuPG v2.0.20 (GNU/Linux) |
| 28 |
|
| 29 |
iF4EAREIAAYFAlIeSl4ACgkQ2ugaI38ACPAzBAEAt5jDJA5uiB4AcS4wPWHjjZA0 |
| 30 |
LtqErcFZuF5kOYLzXSgA/24Oa7GxBguFrLQBWQJDt95IYz8Po76us4BVg4X6/wu8 |
| 31 |
=xrdH |
| 32 |
-----END PGP SIGNATURE----- |
Archives