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@xxxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
