On Fri, Sep 02, 2005 at 09:57:37AM +0200, Marius Mauch wrote: > On 08/29/05 Brian Harring wrote: > > > On Fri, Sep 02, 2005 at 08:17:39AM +0200, Marius Mauch wrote: > > > Don't mind moving them, BUT > > > - metadata is a stupid location for them for several reasons > > being? > > metadata already holds global repository information, time of > > repositories generation, pregenerated cache, glsa set... > > It holds global metadata for the repository. > > a) doesn't exist in CVS Not an arguement against it, since any other directory must also be added.
> b) is generally associated with "populated by cvs->rsync" Only by those who deal in cvs; minority I might add. > c) becomes just another dumping ground (it should only hold the cache > IMO) Whatever directory gets added, suffers the same potential. Regarding the cache, see below. > d) This isn't "metadata" at all The repository is a container of data; the files targeted are data about the repository data. That's the exact definition of metadata, data about data. What's the pregenerated cache, or moreso, what's the cache? data lifted from ebuilds (build data). The naming is apt. Storing the repository metadata in a common directory also makes sense if you consider the fact that people sharing their own repository *may* be distributing a pregenerated cache alongside; it's data that's bound to the specific layout of our current form of ebuild repository. So... I'm not seeing how this is anything but the right location for it. global is a fitting name if it's a global template for ebuilds, something that is directly used in all ebuilds. These files aren't, they're strictly a higher layer of data/descriptions for the data ebuilds group hold/export (p.mask breaks down on this, but it's the sole exception nearest I can figure). ~harring
pgps7HwZbbcR7.pgp
Description: PGP signature
