Pacman

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.
Tasklist

FS#26664 - Extracting only differing files when upgrading packages.

Attached to Project: Pacman
Opened by Thomas Dziedzic (tomd123) - Friday, 28 October 2011, 14:25 GMT
Last edited by Dan McGee (toofishes) - Tuesday, 22 November 2011, 03:45 GMT
Task Type Feature Request
Category Backend/Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 3.5.4
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Summary and Info:
Currently pacman extracts all files from a package when it upgrades a package from version x to version y

I was thinking that instead of doing all this extracting, pacman could keep a list of md5sums of the files in a package.

When a package gets installed which isn't installed currently, it will just extract all the files like it does now.

When a package gets upgraded though, it would check version x's md5sums against version y's md5sums and take the following actions:
version y contains a file in version x, it compares the md5sums and if they don't match, extract that file, else if they match, don't extract.
It would get the list from the original files, in version x, so it doesn't have to compute any md5sums. If a user modifies the files, then overwrite it even if the md5sum of the old file matches the md5sum of the new file.

Some benefits:
minor overhead as far as I can tell
extracting only the files that are needed during upgrade would be less stressful to the hdd. This could also benefit people with ssds.
This task depends upon

Closed by  Dan McGee (toofishes)
Tuesday, 22 November 2011, 03:45 GMT
Reason for closing:  Won't implement
Additional comments about closing:  See comments.
Comment by Karol Błażewicz (karol) - Friday, 28 October 2011, 14:46 GMT
Do you want to make the packages rsyncable?
Comment by Thomas Dziedzic (tomd123) - Friday, 28 October 2011, 16:18 GMT
yes, in a way, I would like pacman to work like rsync in the sense of the algorithm rsync uses to transfer files, and efficiency.

calling it an rsyncable package isn't the word that comes to mind when I describe this since rsync makes sure the contents match.
if we rsync 1 package's contents with / then we will get an empty / with just the package contents ;)
Comment by Thomas Dziedzic (tomd123) - Friday, 28 October 2011, 16:27 GMT
Just thought of another benefit this could bring.
If this get's implemented, we could add another flag to pacman -Q to verify if all the files on your / match the ones in the packages.
Comment by Dan McGee (toofishes) - Tuesday, 22 November 2011, 03:45 GMT
The overhead is not "minor" here, as we would have to stream files out of the archive twice, and rewinding an archive is not possible unless we have unlimited memory or start writing temp files anyway. And you haven't even begun to handle metadata including times, permissions, owners, etc.

The benefit seems academic at best, totally wrong at worst- what if I am trying to reinstall a package to fix some fubar'ed files? Do I need a --no-really-force-this flag? No thanks.

Finally, the check data we can store on all known installed files is something that is addressed in  FS#11091 .

I'm going to close this as "won't implement" due to these various concerns and because I don't want to fool anyone into thinking a bug report is getting looked at.

Loading...