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

[jjacky]

On 02/15/12 23:36, Dan McGee wrote:
> On Wed, Feb 15, 2012 at 10:53 AM, jjacky <i.am.jack.mail at gmail.com> wrote:
>> 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?
> Yes, one would have to do that, unless...
> 
>> 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.
> I was a smart local packager and bumped the pkgrel of the package I
> rebuilt, and then when a new version shows up in the repos, my version
> that I built locally now collides with the version that is in the sync
> repos. Normally this wouldn't be reinstalled, but it could be if
> someone set it as an explicit target.
> 
>> 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?
> If we do this, there will be no option involved, we do not need yet
> another silly knob to tweak. I'm mixed on whether this is a good move,
> but I'm a -1 on adding any sort of option.
> 
>> 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.
> Callbacks already suck; adding another one is also a -1 from me.
> 
>> 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.
> When you're manning the support desk around here, you can make that
> call, but until then, we like to not have to close bugs every time
> preventable problems like this get reported.
> 
> Pro tip, to show that this really isn't a big deal at all and there is
> already a workaround: just add 'file://' to your path and be done with
> it. Bam, the downloader kicks in, copies it to your local package
> cache, and off you go. No new option necessary, no new code, it works
> today.

Oh, nice. Didn't realize this was possible for some reason, thanks. Yeah
that'll work fine.

-j

> 
> -Dan
>