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

[Dan McGee]

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.

-Dan