FS#18012 - Skip copying local packages to cache
Attached to Project:
Pacman
Opened by Pierre Schmitz (Pierre) - Tuesday, 26 January 2010, 07:53 GMT
Last edited by Allan McRae (Allan) - Thursday, 03 September 2020, 01:32 GMT
Opened by Pierre Schmitz (Pierre) - Tuesday, 26 January 2010, 07:53 GMT
Last edited by Allan McRae (Allan) - Thursday, 03 September 2020, 01:32 GMT
|
Details
If you are using a local repository (file://...) pacman
still copies the package to its cache. This is a quite
useless overhead. It would be nice to either disable the
cache for local files or add an option to disable the cache.
|
This task depends upon
Closed by Allan McRae (Allan)
Thursday, 03 September 2020, 01:32 GMT
Reason for closing: Won't implement
Thursday, 03 September 2020, 01:32 GMT
Reason for closing: Won't implement
http://projects.archlinux.org/pacman.git/commit/?id=4476598e4e128f4595d5383ecb51a9576a447b5b
I don't think it's directly related however. With or without that commit, we always did a copy from the file:/ repo to the cache.
The only thing that changed is how we did that copy : let libdownload or external downloader handle it, or do it manually.
It went this way :
1) force libdownload usage for file:/ (this is wrong)
2) handle file:/ manually (this sucks, because libdownload handling is much better)
3) no special file:/ handling (this sucks because wget does not handle file:/ . but its still the best option)
I just thought of an other option, which I don't remember even considering back then :
4) handle file:/ manually when external downloader is used. But this can have the same drawback as 2) : the support by external downloader for file:/ could be better than our own
In all these cases, we never considered to avoid copying the file to the cache. So I believe all the above is off-topic and not relevant to this bug.
Now what do you mean by "it ensures you have a copy of any synced package on your system" ? Are you thinking about mounted network share ?
The first/default cachedir could be a mounted network share itself so it's not a 100% guarantee.
Anyway, my first thought when I read this bug was : why don't we automatically add a file:/ repo as an additional cachedir.
My after thought is : the user can already do that himself, and this gives him more control.
Pierre, what happens if you add the following lines to your pacman.conf :
CacheDir = /var/cache/man/pkg/ # first cachedir = where the uncached files will be cached/downloaded
CacheDir = /path/to/repo/ # second cachedir
I have a bunch of other ideas, probably each being worse than the other...
1) make a distinction in pacman between a primary read/write cachedir and secondary read-only cachedirs
1bis) let the user handle it : if she adds the repo as cachedir to not duplicate files, she should know that -Sc will damage it
2) instead of copying files from file:/ repo to the cachedir, do a symlink instead. This has the usual drawback of file: specific handling : no mtime detection, no good output, no progress bars. Unless we re-implement all of it.
2bis) let the user make a repo-add/repo-remove wrapper to add/remove symlinks from cachedir