Jigdo - A Professional Letter to Mike McGrath

Jonathan Steffan jonathansteffan at gmail.com
Fri Dec 7 01:31:57 UTC 2007


On Fri, 07 Dec 2007 02:10:26 +0100
Jeroen van Meeuwen <kanarip at kanarip.com> 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




More information about the Fedora-infrastructure-list mailing list