Legacy mirror structure

[Matthias Saou]

Warren Togami wrote :

> > I think the solution I like most is :
> > 
> > [...]/SRPMS/repodata/
> > [...]/SRPMS/*.rpm
> > [...]/$basearch/repodata/
> > [...]/$basearch/*.rpm
> > 
> 
> Jesse was earlier grappling with the problem of the ugly symlink for a 
> unified SRPMS for all archs.  Using a structure like this would work 
> wonderfully, while very conveniently placing all archs and the SRPMS at 
> the same level.
> 
> Something like:
> $distnumber/$repository/$basearch/*.rpm
> 
> Example:
> 7.2/updates/SRPMS/repodata/ <--- XML metadata
> 7.2/updates/SRPMS/headers/  <--- yum native headers
> 7.2/updates/i386/repodata/  <--- XML metadata
> 7.2/updates/i386/headers/   <--- yum native headers
> 7.2/updates/base/           <--- non-flat apt genbasedir location (*)
> 7.2/legacy/SRPMS/repodata/
> 7.2/legacy/SRPMS/headers/
> 7.2/legacy/i386/repodata/
> 7.2/legacy/i386/headers/
> 7.2/legacy/base/
>   . . .
> 1/updates/SRPMS/repodata/
> 1/updates/SRPMS/headers/
> 1/updates/i386/repodata/
> 1/updates/i386/headers/
> 1/updates/x86_64/repodata/
> 1/updates/x86_64/headers/
> 1/updates/base/
> 
> Would something like this work?

I would think so. Seems the cleanest to me, unless I'm missing something.
(of course, we've already agreed that "legacy" would be "legacy-addons"
instead, right? ;-))

> * I am not sure if apt works this way or not.  I have never used 
> genbasedir without the --flat option.  Anyone know if anything like this 
> tree structure is possible for the native apt metadata?

I have quite bad memories of trying to get something decent out of apt when
not using --flat. I think that here it would only work if one had :

[...]/SRPMS.$repository
[...]/$basearch/RPMS.$repository

And IIRC, a "base" directory would go into each "$basearch" anyway. It
basically just avoids an SRPMS.$repository inside each $basearch, a first
good step, but some others would still be needed.

I think it's possibly confusing and messes things up if included in the
above with symlinks or something. The other alternatives I can see are :
- Not support apt on the main download.fedoralegacy.org server, let
  "specialized" download servers like download.fedora.us or ayo do what
  they need by themselves if they want.
- Support apt directly only once it uses the common repodata files and
  release "legacy-addons" apt packages only then.
Both the above are compatible and would probably mean having yum be the
only recommended update tool for now (for download made directly from
download.fedoralegacy.org, that is).

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2163.nptl
Load : 0.00 0.10 0.23