Ahmed Kamal wrote:
The drpm generator script does keep drpms on the server only if they are
worth keeping. The worthfulness numbers, of course can be tuned later. I
even think it might be a good idea to make worthfulness depend linearly
on the new rpm size. i.e. keep drpms for large rpms, even if savings are
not that great. We are however getting very good savings on large
packages anyway
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.
(But yes, this is not important yet. This can be implemented later.)
My main focus now is on testing and making sure the "base" system is
working as it should. Any ideas about that regression system? Do you
think it's a good idea? I'm not primarily into coding, so I'll need help
making sound decisions. I'm thinking of having a full FC6 install, then
using drpms to upgrade that into *-testing, that should give us some
nice reports for how many upgrades/reconstructions are failing. We'll
probably need some server to host the drpms on, plus the test client.
I might be missing something here.
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.
For example:
1) rpm -V firefox
2) Uh oh, /usr/lib/firefox-1.5.x.x/foo which is not marked as %config
was modified.
3) Don't attempt to download the drpm.
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?
Warren Togami
wtogami@xxxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
