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

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

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

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