Official presto repositories for Rawhide

[Jonathan Dieter]

On Mon, 2007-06-18 at 18:11 -0400, Jeremy Katz wrote:
> Yeah, this is definitely something we want to start looking at.  The
> question is where in the process does it make sense to generate the
> deltas.  Do we do them in the build system (the koji level)?  Do we do
> them in the update system?[1]  Do we do them at tree compose (mash)
> time?  Each has tradeoffs... not sure which is really the best.  I'm
> pretty sure whichever route we go, we need to go with something that
> preserves the deltas and likely at least stores them in the koji store
> (with info about them in the kojidb).  Perhaps similar to how signing
> works?

I would probably suggest running the script to generated the deltarpms
on a per-package basis rather than a per-repo basis.  The reason for
this is that the script reads in information about *all* the rpms and
deltarpms available, which can take a large amount of time if you're
talking about a full repository.  I don't know enough about our build
system to know where exactly this should go.

> At the same time, I think we should sit down and look at how presto is
> doing things on the yum side to simplify things a bit.  I think that if
> we get rid of the concept of a separate standalone delta repository, we
> can just make it so that there's a (simpler) XML file to parse with the
> delta information and then just add it to the repodata with
> modifyrepo[2].  Then, we can also get rid of the duplication of repo
> code presented by the PrestoRepository class.  I've been trying to get
> to mocking something up, but keep having other things come up and steal
> time instead.  Hopefully tonight/tomorrow...

At the moment, code is in place so that a delta repo added via
updaterepo will be read via yum-presto without needing the whole concept
of a "separate" presto repository.  If you can simplify (or remove) much
of the code in the PrestoRepository class, that would be brilliant.

On a side note, the presto.xml.gz file is in a form such that it could
easily be merged with updates.xml.gz.  Not sure if that's the route we
want to go.

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070619/93a8ad43/attachment.sig>