| 1 |
On 08/29/05 Brian Harring wrote: |
| 2 |
|
| 3 |
> On Fri, Sep 02, 2005 at 09:57:37AM +0200, Marius Mauch wrote: |
| 4 |
> > On 08/29/05 Brian Harring wrote: |
| 5 |
> > |
| 6 |
> > > On Fri, Sep 02, 2005 at 08:17:39AM +0200, Marius Mauch wrote: |
| 7 |
> > > > Don't mind moving them, BUT |
| 8 |
> > > > - metadata is a stupid location for them for several reasons |
| 9 |
> > > being? |
| 10 |
> > > metadata already holds global repository information, time of |
| 11 |
> > > repositories generation, pregenerated cache, glsa set... |
| 12 |
> > > It holds global metadata for the repository. |
| 13 |
> > |
| 14 |
> > a) doesn't exist in CVS |
| 15 |
> Not an arguement against it, since any other directory must also be |
| 16 |
> added. |
| 17 |
|
| 18 |
Was more about "exists in rsync, but not in CVS". Anyway, see below. |
| 19 |
|
| 20 |
> > b) is generally associated with "populated by cvs->rsync" |
| 21 |
> Only by those who deal in cvs; minority I might add. |
| 22 |
> |
| 23 |
> > c) becomes just another dumping ground (it should only hold the |
| 24 |
> > cache IMO) |
| 25 |
> Whatever directory gets added, suffers the same potential. Regarding |
| 26 |
> the cache, see below. |
| 27 |
|
| 28 |
Sure, but then lets give it an appropriate name. |
| 29 |
|
| 30 |
> > d) This isn't "metadata" at all |
| 31 |
> The repository is a container of data; the files targeted are data |
| 32 |
> about the repository data. |
| 33 |
> |
| 34 |
> That's the exact definition of metadata, data about data. |
| 35 |
|
| 36 |
Ah, now I can see where you're coming from, even though I still have to |
| 37 |
disagree. IMO the metadata dir is meant to contain *package* metadata, |
| 38 |
also I don't consider the mentioned files for the most part metadata but |
| 39 |
actually properties of the repo. |
| 40 |
But even ignoring that, I still think it's a very bad idea to mix |
| 41 |
generated and non-generated stuff in the same dir. In my experience that |
| 42 |
often results in problems. That's my main issue. |
| 43 |
|
| 44 |
> What's the pregenerated cache, or moreso, what's the cache? data |
| 45 |
> lifted from ebuilds (build data). The naming is apt. |
| 46 |
|
| 47 |
Did I ever disagree with that? |
| 48 |
|
| 49 |
> Storing the repository metadata in a common directory also makes sense |
| 50 |
|
| 51 |
Agreed, see above though. |
| 52 |
|
| 53 |
> if you consider the fact that people sharing their own repository |
| 54 |
> *may* be distributing a pregenerated cache alongside; it's data that's |
| 55 |
> bound to the specific layout of our current form of ebuild repository. |
| 56 |
|
| 57 |
What has that to do with anything here? |
| 58 |
|
| 59 |
> So... I'm not seeing how this is anything but the right location for |
| 60 |
> it. global is a fitting name if it's a global template for ebuilds, |
| 61 |
> something that is directly used in all ebuilds. These files aren't, |
| 62 |
> they're strictly a higher layer of data/descriptions for the data |
| 63 |
> ebuilds group hold/export (p.mask breaks down on this, but it's the |
| 64 |
> sole exception nearest I can figure). |
| 65 |
|
| 66 |
global == affects/represents all packages in the repo |
| 67 |
|
| 68 |
Btw, I'm not sure you can consider the profiles independent of the repo |
| 69 |
(which I think is one thing you're after with this move). I've thought |
| 70 |
about it in the past too, but in the end they are tied to the repo (use |
| 71 |
flags, archs, cpv instances, ...). Not an argument against the move, |
| 72 |
just something to consider down the road. |
| 73 |
|
| 74 |
Marius |
| 75 |
|
| 76 |
-- |
| 77 |
Public Key at http://www.genone.de/info/gpg-key.pub |
| 78 |
|
| 79 |
In the beginning, there was nothing. And God said, 'Let there be |
| 80 |
Light.' And there was still nothing, but you could see a bit better. |
| 81 |
-- |
| 82 |
gentoo-dev@g.o mailing list |
Archives