| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Robert Buchholz wrote: |
| 5 |
> How is using the eclass better for bandwidth usage? It won't allow for |
| 6 |
> mirroring, and all users would have to checkout the repository from one |
| 7 |
> place. Furthermore, you cannot have (signed) Manifests that allow |
| 8 |
> integrity checks. |
| 9 |
|
| 10 |
- From what I understand of the idea, the eclass will just change the |
| 11 |
SRC_URI field from the first case (sf=tgz) to the second case (->). |
| 12 |
Eclasses have to be sourced before the SRC_URI is determined because |
| 13 |
they can already add (and presumably alter) elements of the SRC_URI |
| 14 |
variable. So I'm not sure how this would directly affect mirroring or |
| 15 |
manifests any more than simply using the -> notation? Could you explain |
| 16 |
what you mean when you say it won't allow for mirroring? |
| 17 |
|
| 18 |
Generating different tarballs is much more of an issue, and would impact |
| 19 |
on manifests too. I guess it's a try-it-and-see situation... |
| 20 |
|
| 21 |
Either way, it seems like the eclass idea would be a good compromise for |
| 22 |
those that don't want gitweb specific workarounds in the package |
| 23 |
manager, but would like to allow the flexibility for people who do? |
| 24 |
|
| 25 |
Mike 5:) |
| 26 |
-----BEGIN PGP SIGNATURE----- |
| 27 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 28 |
|
| 29 |
iEYEARECAAYFAkjBJlYACgkQu7rWomwgFXowcACgt8wHN3OwRN9B19WHXVdn23BV |
| 30 |
xvYAn1URdx9VR3z3wFiRG3RqMTlAxaOC |
| 31 |
=crVS |
| 32 |
-----END PGP SIGNATURE----- |
Archives