Toshio Kuratomi píše v Čt 26. 02. 2009 v 08:24 -0800: > mitr, it would help if you actually answer the question that everyone's > trying to ask even if they aren't phrasing it right :-) > > 1. rpmdb has md5 of old vanilla config file. > 2. rpm package has sha256 of vanilla new config file. > 3. rpm computes md5 of config on filesystem > 4. rpm sees that md5 of config on filesystem and config of vanilla file > differ => user has modified file. > 5. rpm sees the vanilla hashes are of different type. > 6. rpm computes md5 of vanilla new config file. > 7. rpm compares md5 of both vanilla config files to determine whether > the packager has modified the file. > > You told me on IRC that this wasn't realistic because rpm would have to > open the file twice. Care to elaborate so everyone can understand? RPM API users set up a callback that is, among other things, used to provide the downloaded package file to RPM. Calling this callback where it wasn't called before is an API change, possibly breaking the RPM front-ends. Implementing the hash recomputation and verifying the API users was a possibility, but me and Panu consider the current solution good enough - after all, the user's modified config file would be moved to .rpmsave even if the package maintainer only added a comment somewhere; not handling this correctly in rpm does not put any significant additional burden on our users. In addition, if the hashes are recomputed, they must be recomputed only once - decompressing a package five or ten times during a transaction just wouldn't do - and keeping all recomputed hashes in memory would increase memory requirements; I was told that minimizing the increase of memory requirements was a significant reason why the RPM files do not contain both kinds of hashes simultaneously. Mirek -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
