yum-presto not on by default

Jonathan Dieter jdieter at gmail.com
Wed Sep 23 12:22:10 UTC 2009


On Wed, 2009-09-23 at 10:49 +0200, drago01 wrote: 
> On Wed, Sep 23, 2009 at 10:51 AM, Michal Schmidt <mschmidt at redhat.com> wrote:
> > Dne Wed, 23 Sep 2009 07:04:23 +0300 Jonathan Dieter napsal(a):
> >> https://bugzilla.redhat.com/show_bug.cgi?id=524720
> >> https://bugzilla.redhat.com/show_bug.cgi?id=524982
> >>
> >> ...
> >>
> >> The second one has to do with the fact that when rebuilding the rpms,
> >> we have to recompress the data, and xz compression is over 10x slower
> >> than gzip.
> >
> > Do I understand it right that yum-presto compresses the data and then
> > passes them to rpm which decompresses them back again?
> > Why? Is it because it's currently the only way to verify
> > checksums/signatures?
> 
> We had a IRC discussion about this yesterday ... it is not yum-presto
> but delta rpm and it does not make sense at all.
> It should just create uncompressed rpms (assuming rpm can handle them
> which it should) ...according to Seth yum does not care whether the
> rpms are compressed or not.
> 
> So yes the compression is a useless step here.

As I think may have been mentioned elsewhere, the *only* problem is that
the rpm signatures must match and the signatures are over the
*compressed* rpm.

I would *love* to see deltarpm rebuilding uncompressed rpms, but that
will require storing two signatures per rpm in the metadata (compressed
and uncompressed sha256), and either modifying yum to check the
appropriate one, or deltarpm to change the rpm's signature to the
uncompressed one.

I don't think we want to go down the road of having deltarpm-rebuilt
rpms not having their signature checked at all.

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


More information about the fedora-devel-list mailing list