On Fri, 07 Dec 2007 02:10:26 +0100 Jeroen van Meeuwen <kanarip@xxxxxxxxxxx> wrote: > Till Maas wrote: > > On Do Dezember 6 2007, Jonathan Steffan wrote: > > > >> The current updates system is getting better each release, but I > >> think we should adjust our policies to also have an > >> “updates-archiveâ€_ repository. This repository will include all > >> signed updates that had once lived in the updates repo, for the > >> duration of the releases life-cycle. I don't expect all mirrors > >> would want to carry this extra > > > > Once the repositories are presto enabled, an updates-archive with > > all the delta rpms would not take as much space as a full rpm > > repository but provide the same functionality. > > > > If in some way a mirror can regenerate a full, original RPM from all > delta RPMs, so that Jigdo can use it as a slice, a combination of the > two would be possible. This would be nice to be able to utilize the mirrors CPU, but most likely is not practical and we will not be able to accomplished without mirror admins running special handlers and at that point I would expect admins would rather waste the disk space vs supporting a home-brew handler. > Without that ability, all Jigdo recognizes is full RPMs on the ISO > image (slices), against no (zero) matches in the updates-archive/ > folder (all partial slices). Yes, this would require changes to the client software which would basically obsolete the current jigdo client. We would most likely need to utilize yum metadata to put all the pieces back together (not a real problem but it does restrict what platforms we can run pyJigdo on, not that it runs on anything but fedora at the moment) correctly. Using presto is also not as bandwidth efficient, but is more disk efficient (with regards to mirroring an entire tree of archived updates.) I specially left out using presto in the mix because there would be a lot of restrictions placed on where the client software could run if we went this route. I am, however, not in objection to utilizing existing systems we are developing. We would get the benefit of both having delta enabled repos for use with yum and a full archive of all updates released for the duration of a release. Granted multiple deltas would need to be downloaded to achieve a specific version of a package, but that also depends on how the deltas are generated. If anyone knows what the current plan is for generation of deltas, please chime in. Are we doing deltas against the previous public release or are we doing deltas against the release package? In both cases, what is our expected retention policy? -- Jonathan Steffan daMaestro GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59 _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
