Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#23129 - [pacman] option to treat all files as backups
Attached to Project:
Pacman
Opened by Dario Giovannetti (kynikos) - Thursday, 03 March 2011, 23:04 GMT
Last edited by Dan McGee (toofishes) - Monday, 21 March 2011, 14:40 GMT
Opened by Dario Giovannetti (kynikos) - Thursday, 03 March 2011, 23:04 GMT
Last edited by Dan McGee (toofishes) - Monday, 21 March 2011, 14:40 GMT
|
DetailsRecently, due to an upgrade, I've lost some modifications I made to some files in a package, because they were not in its backup array, so no .pacnew file has been created.
My idea would be to have an option to bypass the backup array and treat all files as backups: I know this would slow down a lot an update, but it would make it much safer. Actually there could be some ways to reduce the slow down: - the packages could already contain a text file with all the md5 hashes for each package file (and it should be stored in the database): this would reduce the md5 calculation time to 1/3 (only for the local files); - there could be some sort of white or black list for packages which should or shouldn't be treated with this option; - before the md5 hashes, the file sizes could be compared: if they differ, then there's no reason to calculate the md5 sum; - there could be a limit for the size of files to be treated as backups: all the files above the limit would not be checked unless present in the backup array. Of course, this option should not be enabled by default, but only manually if aware of the consequent slow down. |
This task depends upon
Closed by Dan McGee (toofishes)
Monday, 21 March 2011, 14:40 GMT
Reason for closing: Won't implement
Monday, 21 March 2011, 14:40 GMT
Reason for closing: Won't implement
Anyway close this bug if it's not gonna be implemented ^^