yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement)

[Ahmed Kamal]

>
>
> I meant metadata for the purpose of telling the client which drpms are
> available and which are not because of worthfulness threshold.  This
> might allow us to avoid depending on 404, which would speed up the client.


oops, ok I mis-understood


> Can't rpm know prior to downloading the drpm whether it will be
> successful or not in reconstructing the original RPM?  It can tell by
> using rpm -V to see if the required local data is intact.


Well it can know using this "SEQ" number I talked about. Not sure if using
rpm -V would be equivalent, or why upstream chose this approach. Integrating
SEQ numbers is doable, but not done yet. This list of SEQ numbers can also
be used to avoid the 404s, so definitly this is something we will want to
add

The reconstruction doesn't require the local files marked %config to be
> the original file right?  Any other local files it explicitly doesn't
> rely upon?



Um, not sure. But it does have to reconstruct the new rpm, and that rpm
would have to pass md5/sha1/gpg checks! Doesn't that mean even %config files
have to be untouched?! I need to double check how this is handled

However, when I was talking about a regression test, and getting a list of
failed reconstructions. I mainly meant due to bugs in deltarpm, or the
de-prelinking code as we've seen, not because of changed files.


Warren Togami
> wtogami at redhat.com
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070310/e3c57075/attachment.htm>