On 08/29/05 Brian Harring wrote: > 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.
Was more about "exists in rsync, but not in CVS". Anyway, see below. > > 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. Sure, but then lets give it an appropriate name. > > 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. Ah, now I can see where you're coming from, even though I still have to disagree. IMO the metadata dir is meant to contain *package* metadata, also I don't consider the mentioned files for the most part metadata but actually properties of the repo. But even ignoring that, I still think it's a very bad idea to mix generated and non-generated stuff in the same dir. In my experience that often results in problems. That's my main issue. > What's the pregenerated cache, or moreso, what's the cache? data > lifted from ebuilds (build data). The naming is apt. Did I ever disagree with that? > Storing the repository metadata in a common directory also makes sense Agreed, see above though. > 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. What has that to do with anything here? > 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). global == affects/represents all packages in the repo Btw, I'm not sure you can consider the profiles independent of the repo (which I think is one thing you're after with this move). I've thought about it in the past too, but in the end they are tied to the repo (use flags, archs, cpv instances, ...). Not an argument against the move, just something to consider down the road. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. -- gentoo-dev@gentoo.org mailing list
