Re: yum-presto not on by default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2009-09-23 at 15:22 +0300, Jonathan Dieter wrote:
> On Wed, 2009-09-23 at 10:49 +0200, drago01 wrote: 
> > On Wed, Sep 23, 2009 at 10:51 AM, Michal Schmidt <mschmidt@xxxxxxxxxx> 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.

 No, we have at least 3 problems I think:

1. Nobody wants to download uncompressed rpms, if they don't have
presto.

2. gig signature is over the rpm data (and thus. is over compressed
data).

3. createrepo sha256 data is over the entire rpm (and thus. is over
compressed data).

...but to me this is all a _problem_in_xz_, not presto/deltarpms. If
nobody can fix xz before F12 GA then IMNSO we should revert the
compression to something that works ... the minor savings in xz
compression isn't worth as much as delta's.

-- 
James Antill - james@xxxxxxxxxxxxxxxxx
"I'd just like to see a realistic approach to updates via
 packages." -- Les Mikesell

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux