On 02/15/12 23:36, Dan McGee wrote: > On Wed, Feb 15, 2012 at 10:53 AM, jjacky <[email protected]> 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 >
