On 07/09/2014 10:49 AM, Johnny Hughes wrote: > On 07/09/2014 11:50 AM, Jonathan Dieter wrote: >> We could see about adding a new flag to createrepo; something like >> --deltanewestonly, which would only create deltarpms against the newest >> version of a package available in the repository. > > And a way to remove old ones too? > > Example: > > PackageA1 > PackageA2 > PackageA3 > > A1 is out there and update A2 comes along. We generate drpms. We have > a A1toA2 drpm (and all the other stuff from the rest of the repo, like > firefox and xulrunner and kernel). > > A3 comes out and I generate again. Now I get A1toA3 and A2toA3 ... but > A1toA2 is still there from the old run .. and so are other things I want > to keep). > > I need an easy way to remove A1toA2 without having to delete all and > start over every time ... because I do not want to delete and regenerate > xulrunner, firefox, kernel over again because PackageA2 moved to > PackageA3 (it takes forever to regen from scratch) .. I also don't want > to leave a whole bunch of orphan/unused files there? > > Am I explaining my question in an understandable way? Your explanation makes perfect sense. I did create a tool that was included in very early versions of yum-presto called prunedrpms (see https://git.fedorahosted.org/cgit/presto/tree/presto-utils?id=085c23d840ac0ea28741c0b2c1f471f98de7fa52) that would remove the deltarpms for any rpms no longer in the repo (i.e. the A1toA2 deltarpm in the example you've given). The only problem is that prunedrpms depends on the old rpms being removed from the repository, which I believe CentOS doesn't do. There's also the minor detail that I haven't maintained the presto-utils package since 2009, and retired it in 2011. Another alternative might be to have createrepo first check the previous repository for any valid deltarpms before trying to create a new deltarpm. For this to work, the newly generated repository would need to contain no deltarpms. I don't know enough of the details of how CentOS does a compose to know which of these might be a better solution. Jonathan