| 1 |
On Friday 05 September 2008, Fernando J. Pereda wrote: |
| 2 |
> On Fri, Sep 05, 2008 at 12:39:16AM -0700, Zac Medico wrote: |
| 3 |
> > David Leverton wrote: |
| 4 |
> > > 2008/9/5 Zac Medico <zmedico@g.o>: |
| 5 |
> > >> Both approaches are essentially equivalent but it's a little |
| 6 |
> > >> simpler for ebuild writer if they don't have to customize the |
| 7 |
> > >> output file name. |
| 8 |
> > > |
| 9 |
> > > But is it so much simpler as to justify adding a special |
| 10 |
> > > gitweb-specific hack to the package managers? |
| 11 |
> > |
| 12 |
> > Well, it's not much different from the existing file extension |
| 13 |
> > logic that's already built into the unpack function. I think what |
| 14 |
> > really matters is whether or not the majority of people see it as a |
| 15 |
> > useful extension. |
| 16 |
> |
| 17 |
> I'm wondering why would one fetch a tarball instead of using |
| 18 |
> git.eclass which is much better for both upstream and users (in terms |
| 19 |
> of bandwidth and resources usage). |
| 20 |
|
| 21 |
How is using the eclass better for bandwidth usage? It won't allow for |
| 22 |
mirroring, and all users would have to checkout the repository from one |
| 23 |
place. Furthermore, you cannot have (signed) Manifests that allow |
| 24 |
integrity checks. |
| 25 |
|
| 26 |
I wonder if that is an issue in gitweb in general: Will it generate the |
| 27 |
same tarball every time? If not, that will create issues with users not |
| 28 |
using gentoo mirrors, or the mirroring system itself (because the dev |
| 29 |
could commit a Manifest for another file than the server delivers |
| 30 |
later). |
| 31 |
|
| 32 |
For what it's worth, I also see no reason to double functionality for |
| 33 |
one special case where we also create a solution for the more general |
| 34 |
one. |
| 35 |
|
| 36 |
Robert |
Archives