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#313 - "patch" packages

Attached to Project: Pacman
Opened by Ben Mazer (contrasutra) - Tuesday, 16 December 2003, 03:45 GMT
Last edited by Judd Vinet (judd) - Wednesday, 07 January 2004, 08:11 GMT
Task Type Bug Report
Category
Status Closed
Assigned To Judd Vinet (judd)
Architecture not specified
Severity Very Low
Priority Normal
Reported Version 0.6 Widget
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

I believe RPM has this feature, and SUSE uses it for some things. Basically, we need a "patch" package-type for pacman. In the current system, changing one file in XFree86 forces people to download a 70MB package.

With a "patch" system, people can download small, incremental packages, even between versions. (eg. apache 2.0.47-2.0.48). Though I think this would be most useful between same-version releases (-1, -2 releases) as usually, only a few files are changed/added.

This is becoming increasingly more important, as many repackages are coming out within a few hours. I'm reminded of the recent perl and 2.4.23 kernel troubles. On dialup, I was forced to download almost 60MB worth of files, for what should have been only 20MB.

What would be nice, is an automatic patching system for ABS too. It would compare two packages and create a patch.

Also, this would allow Arch to have a "security update" type track, as the current "stable"/"current" system doesn't leave room for people who want to run a stable server, but still recieve security updates.

Now, you could simply patch for security updates, as often, it's only a few files affected.

Thanks,
Ben.
This task depends upon

Closed by  Judd Vinet (judd)
Saturday, 03 July 2004, 04:30 GMT
Reason for closing:  Won't implement
Comment by Dale Blount (dale) - Tuesday, 06 January 2004, 22:57 GMT
I've done some preliminary research on this here are the file sizes:

56642527 xfree86-4.3.0-6.pkg.tar.gz
55763815 xfree86-4.3.0-7.pkg.tar.gz
55751183 xfree86-4.3.0-6-4.3.0-7.patch

The patch is a mere 12K smaller than the full package update and took almost a half hour to create and 10 minutes to patch on a 2.8ghz P4.

More testing is needed on other applications, and of course multi-revision patches might need to be created, as well as viability for patches to actually be usefully smaller.

Dale
Comment by Jason Chu (jason) - Saturday, 10 January 2004, 20:37 GMT
Just a thought, I bet making diffs of the uncompressed files would make them smaller... and also take up more cpu and temporary disk space.
Comment by Andreas Schweitzer - known as andy elsewhere in AL (aschweitzer) - Sunday, 11 January 2004, 22:30 GMT
That was my very first thought, too :
don't make the diff on the pkg.tar.gz files.

For a minimal patch do the diff between the UNPACKED tar balls. Of course that won't help in distributing the patch ...

However, as the next best thing you should assure that the order in the tar archives is the same. I realize that this leads to complications, too, like the "standard" update on the ftp server might be different (if only in MD5) then the one the users gets with the binary patch.

Of course, I completely ignore disk and CPU considerations :-)

Loading...