Legacy mirror structure

Jesse Keating jkeating at j2solutions.net
Mon Jan 19 16:45:16 UTC 2004


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

On Monday 19 January 2004 08:33, Matthias Saou wrote:
> Indeed, silly me. Then wouldn't using the same layout as Red Hat is
> currently using for FC development be best? It's having "SRPMS" and all
> arch directories beside each other in the version or component
> directory.
>
> [...]/redhat/$releasever/{updates,..}/{SRPMS,i386,ia64,..}/{headers/,*.r
>pm}
>
> > I wish to use something close to that, but maintain my SRPM links for
> > multiarch space concerns.
>
> Wit the above, you don't really need any kind of symlink, although for
> Fedora Core, Red Hat has create one within all $basearch which points to
> ../SRPMS IIRC.
>
> At a quick glance, this conforms to Warren's recommendations, as long as
> the base ftp/rsync directory/module name is "fedoralegacy". I'm also all
> for using the "legacy-addons" name for the legacy-specific additional
> packages, as we've already seen confusion on the list as to where the
> "legacy updates" packages were actually located.
>
> http://download.fedoralegacy.org/redhat/$releasever/<mod>/SRPMS/headers
> http://download.fedoralegacy.org/redhat/$releasever/<mod>/SRPMS/*.rpm
> http://download.fedoralegacy.org/redhat/$releasever/<mod>/$basearch/head
>ers
> http://download.fedoralegacy.org/redhat/$releasever/<mod>/$basearch/*.rp
>m
>
> With "<mod>" in : base, updates, testing-updates, legacy-addons
> The headers in SRPMS could probably be omitted to not increase even more
> the number of files to consider for each mirror rsync run, as they are
> not useful or used AFAIK.

Again, your running into a situation where the end user would have to have 
an explicit "SRPM" yum/apt config line.  With my structure the [updates] 
section itself supports both RPMS and SRPMS.  This seems far less 
confusing to the end user.

> Oh, another concern : Is there any plan to include any debuginfo
> packages? It could then be something like this? :
> [...]/fedora/$releasever/updates/$basearch/debug/{headers/,*.rpm}
>
> But the headers for the non-debug packages would then contain the debug
> ones too...

Yes, difficult thing to think of.  Perhaps it would be feasable for the 
master mirror to hold the correct headers/ file that has SRPMS and debug 
stuff, but have a mirror.headers/ directory that is the result of ignoring 
the SRPMS and the debug stuff.  I personally don't wish to include debug 
stuff.  If the end user wants debug, they can download the SRPM and build 
it themselves.  But a headers/ and a headers.nosrpms/  would be useful for 
mirror folks.

- -- 
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)

iD8DBQFADAmc4v2HLvE71NURAhcIAJ0UXs7+zpgTfqdfCeZuoJrnyA5kXgCfQRHW
mVntqafPD6WMH8mULdC0rTk=
=ifeb
-----END PGP SIGNATURE-----





More information about the fedora-legacy-list mailing list