On Friday 05 September 2008, Fernando J. Pereda wrote: > On Fri, Sep 05, 2008 at 12:39:16AM -0700, Zac Medico wrote: > > David Leverton wrote: > > > 2008/9/5 Zac Medico <[EMAIL PROTECTED]>: > > >> Both approaches are essentially equivalent but it's a little > > >> simpler for ebuild writer if they don't have to customize the > > >> output file name. > > > > > > But is it so much simpler as to justify adding a special > > > gitweb-specific hack to the package managers? > > > > Well, it's not much different from the existing file extension > > logic that's already built into the unpack function. I think what > > really matters is whether or not the majority of people see it as a > > useful extension. > > I'm wondering why would one fetch a tarball instead of using > git.eclass which is much better for both upstream and users (in terms > of bandwidth and resources usage).
How is using the eclass better for bandwidth usage? It won't allow for mirroring, and all users would have to checkout the repository from one place. Furthermore, you cannot have (signed) Manifests that allow integrity checks. I wonder if that is an issue in gitweb in general: Will it generate the same tarball every time? If not, that will create issues with users not using gentoo mirrors, or the mirroring system itself (because the dev could commit a Manifest for another file than the server delivers later). For what it's worth, I also see no reason to double functionality for one special case where we also create a solution for the more general one. Robert
signature.asc
Description: This is a digitally signed message part.
