FS#6404 - pacman -U/-A leaves remote files in current dir

Attached to Project: Pacman
Opened by Callan Barrett (wizzomafizzo) - Monday, 12 February 2007, 08:57 GMT
Last edited by Dan McGee (toofishes) - Friday, 05 October 2007, 01:06 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture All
Severity High
Priority Normal
Reported Version 2.9.8
Due in Version 3.1.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

When running something like 'pacman -U http://foo.com/this/is/a/package.blah'; pacman will leave any files it downloads in the current dir. It would be nice if they were moved to the cache dir of pacman instead of being left randomly in my home dir with root permissions attached to it.
This task depends upon

This task blocks these from closing
 FS#8109 - Pacman 3.1 Release Roadmap 
Closed by  Dan McGee (toofishes)
Friday, 05 October 2007, 01:06 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed in 3.1
Comment by Roman Kyrylych (Romashka) - Monday, 12 February 2007, 10:22 GMT
What version of pacman?
Comment by Callan Barrett (wizzomafizzo) - Monday, 12 February 2007, 10:26 GMT
Version 2 and 3.
Comment by Aaron Griffin (phrakture) - Monday, 12 February 2007, 16:07 GMT
We talked about this in IRC. Basically, because 2 did it this way, I'm fine with letting 3 do it as well. Thus this is an FR, and not really needed for the 3.0 release.
Comment by Scott H (stonecrest) - Tuesday, 13 February 2007, 03:24 GMT
Where do I get a .blah package from?

(I second this idea, it has always required one extra step.)
Comment by Dan McGee (toofishes) - Monday, 09 July 2007, 20:36 GMT
Anyone want to fix this one? Should be pretty easy to download to /tmp or something, or download straight to the cache.
Comment by Glenn Matthys (RedShift) - Sunday, 19 August 2007, 18:05 GMT
I would even see this as expected behaviour: someone might want to keep that package for later, and when he goes looking for it he doesn't find it anymore? Putting it in the cache has no use because the package isn't pulled in from a repository. If we fix this by deleting the downloaded package, we must be carefull to not delete packages that are installed like this: pacman -U /home/glenn/my-awesome-package-1.0-1-x86_64.pkg.tar.gz
Comment by Dan McGee (toofishes) - Sunday, 19 August 2007, 22:03 GMT
I disagree that it is no use to put it in the cache dir- this cache dir is currently used 'exclusively' by sync downloads, but there is really no guideline telling us that is what it is for. The only alternative I would see is always downloading it to /tmp or something like that.
Comment by Glenn Matthys (RedShift) - Monday, 20 August 2007, 06:40 GMT
Hmmm I lik the idea of always downloading it to /tmp.
Comment by Callan Barrett (wizzomafizzo) - Monday, 20 August 2007, 07:51 GMT
Once again, why can't you back up anything you say with a real argument? I can live with them being put in /tmp just fine but it seems pointless when we have a perfectly good *cache* directory for *caching* packages. If I install a package directly from a URL and it *caches* the package for any later use I think the first place I would look is my pacman *cache* directory (you know, the directory made for caching packages?) and not /tmp.
Comment by Simo Leone (neotuli) - Monday, 20 August 2007, 07:56 GMT
except that /tmp may be a small ramdisk on many systems, depending on configuration, so a large package may run it out of space rather quickly.
Comment by Glenn Matthys (RedShift) - Monday, 20 August 2007, 07:57 GMT
I like the idea of putting it in /tmp because it will be cleared on next boot, and otherwise it will leave a file with root as owner in the directory where he or she ran pacman. Now that you've explained your vision, putting it in the pacman cache idea does sound better.
Comment by Glenn Matthys (RedShift) - Monday, 20 August 2007, 07:58 GMT
I just read neutuli's remark, very true, I vote we download straight to the pacman cache dir.
Comment by Dan McGee (toofishes) - Monday, 20 August 2007, 19:36 GMT
Hopefully fixed/implemented in GIT in my working tree.

Loading...