On Wed, Feb 15, 2012 at 7:39 AM, jjacky <[email protected]> wrote: > Hey, > > So I would be interested in such a feature, and I found it being > rejected as FS#15143, but I have some questions. > > It seems the main reason it was rejected was this: > > " > My second argument against this is that users sometimes do local rebuild > of official packages, and maybe don't want to mix these packages with > official ones in the cache (which could cause integrity check failures > next time they upgrade their system). > " > > And I don't understand. Why/how would there be an integrity check > failure on upgrade ? > > I thought integrity check meant that the package(s) about to be > installed was being checked. So, during an upgrade, there would be no > reason to check this already installed package, no? > > And if there was an update available, it's the integrity of the newly > downloaded package that would be checked, and it would have no reason to > fail. > > What am I not understanding/misunderstanding here? > > Because I do like this idea and, unless there is an inherent problem > with it of course, I might be interested into looking to make a patch to > add such an option.
Every time you rebuild a package, the md5sum, sha256sum, and PGP signature would be different on the resulting file. If I build foobar-1.0-1 from ABS without bumping the pkgrel, it doesn't matter whether I tweak anything in the PKGBUILD or not, the package file produced is different. If I install that with -U, I'm likely OK- we have no md5 or sha256 checksum to use, and likely no errant .sig file in the same directory. However, if I try to reinstall a package with -S that I've rebuilt locally, fireworks and failure will result- neither the checksums nor the PGP signature in the sync database will match your rebuilt package that has been cached rather than the real one. -Dan
