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

[Warren Togami]

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 at redhat.com