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
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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
Comment by KaiSforza (KaiSforza) - Sunday, 03 February 2013, 21:36 GMT
This pretty much makes no sense. You can put a pacman cache anywhere. Just set a PKGDEST in your makepkg.conf if you want something like a pacman cache for your personal packages.
Comment by Mark E. Lee (bluerider) - Sunday, 03 February 2013, 21:50 GMT
While users can edit PKGDEST in their makepkg.conf, I think this feature should be enabled by default since pacman is managing those user packages without backing up the actual package it installed. I feel that defeats the purpose of package management.
Comment by KaiSforza (KaiSforza) - Sunday, 03 February 2013, 21:53 GMT
You can also install packages and delete the file. Pacman doesn't manage the backups, it manages the files that are installed. The archives are just how they get out. Also, you can specify multiple package caches if you want. Make the second pacman cache your PKGDEST and you'll get the same behavior you are looking for. Or you can manage your own pacman repository based in your PKGDEST. That will copy the files into your pacman cache.

EDIT: When using pacman -S pkgname that is.
Comment by Mark E. Lee (bluerider) - Sunday, 03 February 2013, 22:45 GMT
If pacman's job is to only manage the files that are installed, why would it have a cache in the first place? On https://wiki.archlinux.org/index.php/Downgrading_Packages; it mentions that package downgrading can be done trivially by visiting pacman's cache. This does not apply to AUR/custom built packages since these packages aren't stored in pacman's cache.

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.
Comment by Dave Reisner (falconindy) - Sunday, 03 February 2013, 22:47 GMT
You can already do this:

pacman -U file://foo.pkg.tar.xz

This will be seen as a remote URL and downloaded to the package cache.
Comment by Mark E. Lee (bluerider) - Sunday, 03 February 2013, 22:54 GMT
Is there a particular reason why "-U" doesn't store a copy in the package cache (if we don't use the remote url)?
Comment by Dave Reisner (falconindy) - Sunday, 03 February 2013, 22:55 GMT
Because it's already local.
Comment by Mark E. Lee (bluerider) - Sunday, 03 February 2013, 23:09 GMT
I feel that it would be more consistent of pacman if it also kept a backup of the files in its own cache. That way, if pacman's database were to be corrupted. If users already have a copy of the output of `pacman -Qm` they can go to the pacman cache to reinstall custom built packages too.
Comment by Dave Reisner (falconindy) - Sunday, 03 February 2013, 23:44 GMT
And I think it's silly to willfully duplicate a package which is already on disk. Set your PKGDEST to something appropriate in /etc/makepkg.conf, and add that to your CacheDir list in /etc/pacman.conf.
Comment by Mark E. Lee (bluerider) - Monday, 04 February 2013, 01:10 GMT
If you are trying to indicate that my opinion doesn't matter by calling it "silly" then you obviously value ego over stability.

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?
Comment by KaiSforza (KaiSforza) - Monday, 04 February 2013, 01:20 GMT
It just doesn't make sense to have two copies of the package on your system. If you want to keep backups, or are doing the things you mentioned, then you should be doing that manually anyway.

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.
Comment by Dave Reisner (falconindy) - Monday, 04 February 2013, 01:27 GMT
> Say what if the user experiences a deleterious fsck that deletes the package. How are they supposed to retrieve that particular version?
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.

Loading...