Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Brian Harring <ferringb@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]