On 02/15/12 14:53, Dan McGee wrote: > 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.
Ok, I think I got it. But that means it would only happen if one was to do a pacman -S foobar (after having compiled/-U that package), right? I thought the "would case failure on next upgrade" meant upgrading the package to a new version, or even just the next -Syu, but that is not the case. So to have the failure, one would need to: - build a package and install it (-U) w/out changing its name (and have that new option to copy local packages to the cache of course) - then, decide to "restore" the original package, through a -S Well, in that case I don't really see that as a problem. If one does do that, the error is to be expected after all. (And easy to fix: remove the file from the cache) Do you feel that because of this, having an option in pacman.conf to copy files installed with -U to the cache is a bad idea? Besides, I was thinking anyway that when this copy to the cache occurs, pacman would first check if there's already a file by that name in there, and if so ask whether to overwrite it or not. Which means, if one says yes in such a case, knowingly replacing the official package with their own rebuild in the cache, I'd say they must be ready to face the consequences. -j > > -Dan >
