On Mon, Oct 6, 2014 at 9:55 PM, Jonathan Dieter <jdieter@xxxxxxxxx> wrote: > On 10/06/2014 08:57 PM, Reindl Harald wrote: >> >> Am 06.10.2014 um 19:45 schrieb Florian Festi: >>> >>> The way of getting around all this unnecessary computation is >>> establishing trust via the deltarpm itself and giving up the idea of >>> reconstructing the originally rpm as a prove of everything worked out >>> just fine. >>> >>> To save even more time the delta would need to be applied directly on >>> disk without creating an package at all. This would require a deeper >>> integration with rpm and requires some tricky algorithms to make sure >>> everything is ok in advance and won't blow up during the rpm >>> transaction. So if anyone needs a hobby... >> >> >> oh no - don't tie all together for reasons which did not destory the >> world over years - it is a damned good design that the part dealing with >> rpm packages don't need to know anything aboutt delta rpms because the >> normal packages are created before that step >> >> don't break the unix-way of work the current behavior follows for no >> good reason and there is none - otherwise deltarpm would not have been >> default over years the way it works now > > > Ok, granted, this sounds pretty scary. But if we give rpm the ability to > upgrade an installed package with a deltarpm, it wouldn't take away > deltarpm's ability to generate a full rpm from a deltarpm. And it does have > the advantage of cutting right through the knot. We already store checksums > of the deltarpms in prestodelta.xml, as well as in the deltarpm itself. > > Probably the biggest weakness would be the chance that something would > change on-disk between the check stage and actual install stage. We'd have > to evaluate whether it's worth making a temporary copy of the old data > during the check stage and then applying the deltarpm to that. > > All of this would require a lot of buy-in from the rpm guys, though > (Florian, you're one of them, right?). If I recall correctly, when we first > looked at deltarpms, one of the selling points was that rpm didn't have to > change at all. > > Jonathan > > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Hi, I live in a country where 1 Mbps (128 KB/s) is more than the average (and considered GOOD), we really need deltarpm, it saves huge amounts of data and time. I think the problem is in compressing then decompressing the file, why we don't take checksum of the tar file before compression? (of course this must be done on the server too), this way we can use deltarpm without much CPU, this should provide the best of the two worlds. Mustafa Muhammad -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
