Legacy mirror structure

Jesse Keating jkeating at j2solutions.net
Tue Jan 20 16:26:16 UTC 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 20 January 2004 04:15, Matthias Saou wrote:
> Well, currently, the (yum) headers for SRPMS are not used for anything
> AFAIK. And as for having them included on a single config line along
> with the binary packages, it may be better to have exactly the opposite.
> With apt for instance, you're much better off not having "rpm-src" lines
> enabled in your configuration if you don't plan on using "apt-get
> source" very often. You save bandwidth as well as execution time.

Currently they are not used, but in the future yum will support source 
downloading.  I think you might have finally convinced me to seperate out 
the SRPMS into their own repository.  It's not going to be clean for the 
conf file, but we can comment them out to save the user bandwidth.  I will 
however still put them on the server.

> Anyway, wouldn't it be better to directly concentrate on the integration
> of the new common repodata files? The logical evolution is that it'll
> become the main supported server-side metadata format, so IMHO it's the
> most important to start thinking of now.

I have been thinking of this since day one, it's just that from all that 
I've heard, the repodata works a lot like yum's metadata, so this is how I 
structured the server.  metadata does handle source rpms.

> How will it handle binary vs. source sets of packages? AFAICT, it
> doesn't make any special difference between both, but as I said above,
> it may be interesting to decide to separate them if it can lower to
> amount of transfered data when minor changes occur (e.g. one new
> update).
>
> I think the solution I like most is :
>
> [...]/SRPMS/repodata/
> [...]/SRPMS/*.rpm
> [...]/$basearch/repodata/
> [...]/$basearch/*.rpm

I think you're missing a few directories there.  Try this:

[...]/SRPMS/repodata
[...]/SRPMS/base/*.rpm
[...]/SRPMS/updates-testing/*.rpm
[...]/SRPMS/updates/*.rpm

[...]/i386/repodata
[...]/i386/base/*.rpm
[...]/i386/updates-testing/*.rpm
[...]/i386/updates/*.rpm

I'm making an assumption here that the repo data can be ran at a higher 
level than yum-arch can, and hold info about different repo subdirs.

> With a default configuration which only fetches metadata for $basearch
> packages but with the ability to easily enable fetching it for source
> packages too. Just as you said concerning the debug packages, that very
> few people actually need them, the same applies (in a different
> proportion) to source packages IMHO.

Right, I think more people will be browsing the tree for SRPMS rather than 
using package tools.  I'm fiddling with http://download.fedoralegacy.org 
today to make a real copy of my intended layout.

- -- 
Jesse Keating RHCE MCSE	(http://geek.j2solutions.net)
Fedora Legacy Team	(http://www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam		(www.mondorescue.org)
GPG Public Key		(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFADVao4v2HLvE71NURAnZpAKCDwFmlL+sSsc/pehei90JKQiP1KQCggNi0
sr/cMGjtA1OumhkQfeHXbmA=
=O8VV
-----END PGP SIGNATURE-----





More information about the fedora-legacy-list mailing list