Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
Date: Mon, 29 Aug 2005 10:05:13
Message-Id: 20050829100154.GG18464@nightcrawler
In Reply to: Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir by Marius Mauch
1 On Fri, Sep 02, 2005 at 09:57:37AM +0200, Marius Mauch wrote:
2 > On 08/29/05 Brian Harring wrote:
3 >
4 > > On Fri, Sep 02, 2005 at 08:17:39AM +0200, Marius Mauch wrote:
5 > > > Don't mind moving them, BUT
6 > > > - metadata is a stupid location for them for several reasons
7 > > being?
8 > > metadata already holds global repository information, time of
9 > > repositories generation, pregenerated cache, glsa set...
10 > > It holds global metadata for the repository.
11 >
12 > a) doesn't exist in CVS
13 Not an arguement against it, since any other directory must also be
14 added.
15
16 > b) is generally associated with "populated by cvs->rsync"
17 Only by those who deal in cvs; minority I might add.
18
19 > c) becomes just another dumping ground (it should only hold the cache
20 > IMO)
21 Whatever directory gets added, suffers the same potential. Regarding
22 the cache, see below.
23
24 > d) This isn't "metadata" at all
25 The repository is a container of data; the files targeted are data
26 about the repository data.
27
28 That's the exact definition of metadata, data about data.
29
30 What's the pregenerated cache, or moreso, what's the cache? data
31 lifted from ebuilds (build data). The naming is apt.
32
33 Storing the repository metadata in a common directory also makes sense
34 if you consider the fact that people sharing their own repository
35 *may* be distributing a pregenerated cache alongside; it's data that's
36 bound to the specific layout of our current form of ebuild repository.
37
38 So... I'm not seeing how this is anything but the right location for
39 it. global is a fitting name if it's a global template for ebuilds,
40 something that is directly used in all ebuilds. These files aren't,
41 they're strictly a higher layer of data/descriptions for the data
42 ebuilds group hold/export (p.mask breaks down on this, but it's the
43 sole exception nearest I can figure).
44 ~harring

Replies