[pacman-dev] Move package to cache when installed with -U

[jjacky]

On 02/15/12 14:53, Dan McGee wrote:
> On Wed, Feb 15, 2012 at 7:39 AM, jjacky <i.am.jack.mail at gmail.com> 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
>