FS#33693 - [pacman] PLEASE ENTER SUMMARY
Attached to Project:
Pacman
Opened by Mark E. Lee (bluerider) - Sunday, 03 February 2013, 21:22 GMT
Last edited by Dave Reisner (falconindy) - Sunday, 03 February 2013, 23:45 GMT
Opened by Mark E. Lee (bluerider) - Sunday, 03 February 2013, 21:22 GMT
Last edited by Dave Reisner (falconindy) - Sunday, 03 February 2013, 23:45 GMT
|
Details
Description:
pacman -U doesn't add the user package to /var/cache/pacman/pkg/ It would be beneficial for user packaging if user packages were also stored in pacman's cache to allow user package downgrading. |
This task depends upon
Closed by Dave Reisner (falconindy)
Sunday, 03 February 2013, 23:45 GMT
Reason for closing: Won't implement
Additional comments about closing: This functionality already exists with proper configuration
Sunday, 03 February 2013, 23:45 GMT
Reason for closing: Won't implement
Additional comments about closing: This functionality already exists with proper configuration
EDIT: When using pacman -S pkgname that is.
I feel modifying the "-U" behavior to store a copy of package in pacman's cache would work require the least number of changes on the user side (probably a very small number of changes on the developer's side) and fit the wiki's description.
pacman -U file://foo.pkg.tar.xz
This will be seen as a remote URL and downloaded to the package cache.
Maybe you understand something I don't. Can you enlightenment me why pacman should not have a backup of all packages it has installed in a consistent directory without resorting to insults?
Say what if the user experiences a deleterious fsck that deletes the package. How are they supposed to retrieve that particular version? Rebuild it with a PKGBUILD that could be lost? How will the user determine which compiling options screwed up a new version of a program?
How is it KISS to edit two files from the user side, instead of simply changing what is probably one line of code in pacman to make it more consistent.
What do you value more? Consistency or deeming something silly?
How is it KISS to have two possibly multi-gigabyte files on your hard drive when you could have just one? That just seems wasteful.
Ok, and what happens when that same fsck wrongly nukes the filesystem where your cache resides? In either case, you can "retrieve" it by rebuilding it.
> Rebuild it with a PKGBUILD that could be lost?
If you're concerned about data loss, please invest in a backup strategy. This is way outside of the realm of package management. Additionally, PKGBUILDs aren't generally complex. They can be rewritten. I fail to see how this supports your point.
> How is it KISS to edit two files from the user side, instead of simply changing what is probably one line of code in pacman to make it more consistent.
Patches welcome if you really think this is a one line change.
> What do you value more? Consistency or deeming something silly?
Neither. I value simplicity. Remotely downloaded files are placed in the cache. Local files are already local and already have a place on disk. It's entirely within your power to change that location as you desire.