[mirror-admin] rsync and updates-testing -> updates-released

[Carlos Carvalho]

J.H. (warthog19 at eaglescrag.net) wrote on 21 July 2009 18:59:
 >
 >Carlos Carvalho wrote:
 >> Jesse Keating (jkeating at redhat.com) wrote on 21 July 2009 18:35:
 >>  >On Tue, 2009-07-21 at 22:18 -0300, Carlos Carvalho wrote:
 >>  >> Hurray!
 >>  >> 
 >>  >> There's nothing crazy, it's just a much better way to do. It'd get rid
 >>  >> of the entire mess of hardlinks.
 >>  >> 
 >>  >> That's how Debian does it.
 >>  >> 
 >>  >> You can also join all the archs together, since the arch is in the
 >>  >> name of the packages. Those who exclude archs would just have to make
 >>  >> a small change in their exclude patterns. You could post the
 >>  >> conversion example on the mirroring instructions page.
 >>  >> 
 >>  >> It's even possible to join releases, as Debian does. The advantage is
 >>  >> that packages that are the same among releases only need to appear
 >>  >> once in the repository. However this makes it hard to exclude a
 >>  >> release, it needs detailed knowledge on the repository structure.
 >>  >> Further, since you say the sign key changes, the same file
 >>  >> cannot be used for more than one release; thus this level of merging
 >>  >> doesn't seem to be useful for fedora.
 >>  >
 >>  >I got some resistance to using relative dir information in the repodata,
 >>  >so instead we could still put all the packages for updates in a single
 >>  >dir, and make hardlinks further into updates vs testing and then create
 >>  >metadata from the hardlinks.  It'll look like duplicate data, but due to
 >>  >hardlinks they transfers won't care.
 >> 
 >> This removes much of the advantage of the method. Why don't you put
 >> absolute paths then?
 >
 >Absolute won't work as not all the mirrors have the data in the exact 
 >same place.  The data either needs to be relative or hard-linked, if 
 >relative is getting shot down for whatever reason hard-linked is about 
 >as good as it's going to get sadly.  That said if the packages are all 
 >still under the same category it shouldn't be a big deal.  I.E. update 
 >package live under updates/ etc.

Right now they cannot be absolute for the same reason. I meant
"absolute" starting from the root of the mirror tree, of course.

--