11

Is there any way to get source diffs between a locally-installed package and its updated one? This will be useful to check exactly which parts have been fixed, changed or added.

For example, say you have the linux-libc-dev package installed on your system and

sudo apt-get update && sudo apt-get upgrade

shows

The following packages will be upgraded:
  linux-libc-dev

but you want to check, before upgrading it, the exact changes that have been made compared to your local version of the same package.

How can we do it?

Improve this question

5 Answers 5

Reset to default
7

Afaik the only way to do this is to get the source and make the diff's your self. You can get the actual source used for compiling the packages with apt-get. fx:

apt-get source gwibber=2.30.2-0ubuntu3 gwibber=2.30.0.1-0ubuntu1
diff -rupN gwibber-2.30.0.1/ gwibber-2.30.2/

This will print out all differences between all files in a standard patch format.

Improve this answer
3
  • 1
    This is pretty good. The only thing I'd change in the example is to use “debdiff gwibber_2.30.0.1-0ubuntu1.dsc gwibber_2.30.2-0ubuntu3.dsc” rather than raw diff.
    – RAOF
    Oct 24, 2010 at 1:28
  • 1
    Well it does practically the same thing, but you can use diff on every package/tarball out there. Maybe someone want to see the diff between an svn-trunk and the current pkg.
    – LasseLuttermann
    Oct 24, 2010 at 8:19
  • My second answer (whatchanged) essentially automates this.
    – mgunes
    Oct 24, 2010 at 10:54
5
+50

Here's another solution I hacked together: whatchanged.

It takes the name of the binary package you're interested in as the only argument. To use a recent SRU as an example:

./whatchanged python_papyon

This is what it does:

  1. Check if there's an update candidate; exit if there's none
  2. If a candidate exists, create temporary directories and fetch the source packages for both the installed version and the candidate into them
  3. Compare the two with debdiff and output to stdout (you'll probably want to redirect for easier reading)
  4. Clean up the temporary directories.

It probably needs to better handle certain things that may go wrong during source retrieval, the flow control is probably a bit off, and there must be more elegant ways for version checking, but it worked fine in my limited testing so far. For now, consider it a quick hack that works, and improvements are most welcome. I'll push it to a bzr repository and/or create a Launchpad project if it's useful to a few people.

Edit: Rather than let it rot on pastebin, I've started a Launchpad project for it; you can get the latest trunk revision with bzr branch lp:whatchanged. Feel free to report bugs, branch it, rewrite it in Perl, etc.

Improve this answer
2
  • How nice! Developing tools as answers ;) Like you coding style, but would properly have coded it in perl..
    – LasseLuttermann
    Oct 24, 2010 at 20:42
  • Thanks; hope it's of use. The way packaging and release technicalities sometimes make open code seem opaque is something that's been on my mind, and I haven't found any simple tools to overcome that with, so someone expressing a need for the exact same thing was a good motivation to finally make a primitive one myself.
    – mgunes
    Oct 25, 2010 at 9:22
2

Here's one (probably not optimal) UDD way of doing it:

Pull -updates branch for your release (assuming Lucid) that (assumption follows) should contain the latest SRU:

bzr branch lp:ubuntu/lucid-updates/package_name

Get the changes introduced by the latest revision, which (assumption follows) should correspond to the latest SRU:

bzr diff -c`bzr revno`
Improve this answer
7
  • 2
    Hmm. It is an interesting take, though it is probably less comprehensive than Source Lab's in a sense that the package names may not match, or exist in, the bzr source tree.
    – Gödel
    Oct 19, 2010 at 23:56
  • As long as you know the source package name, it will match. You can find which source package a binary package is produced by with apt-cache show package_name | grep Source:.
    – mgunes
    Oct 20, 2010 at 0:09
  • @Murat Well, <package_name> so obtained doesn't work on some packages: bzr branch lp:ubuntu/lucid-updates/$(apt-cache show linux-libc-dev | grep -m 1 Source: | awk "{print \$2}") => bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/lucid-updates/linux": no supported schemes
    – Gödel
    Oct 20, 2010 at 0:21
  • That's because there are no Ubuntu branches for the kernel at all, I'm afraid. It could be a specific exception due to the fact that the kernel is maintained in git (kernel.ubuntu.com) but I'm not sure about the exact scope of the bzr package branches at this time. You may want to ask on #ubuntu-devel.
    – mgunes
    Oct 20, 2010 at 0:31
  • @Mural I know. That's why the method is less comprehensive than Source Lab's. But again, it is an interesting take.
    – Gödel
    Oct 20, 2010 at 0:41
0

If you want to see file differences in the package archives, extract their md5sums files, sort and diff those, and then you can narrow the list of actual files to compare dramatically.

Improve this answer
-1

May not be the "exact" changes, but apt-listchanges lists the changelog entries for the changes that have been made since the installed version.

It works by adding a step after you finish downloading the new packages, but before the installation starts, where it shows you the changelog entry for each package about to be upgraded. You can then continue or cancel. You can install it with

sudo apt-get install apt-listchanges

then set it up with

sudo dpkg-reconfigure apt-listchanges
Improve this answer
2
  • Again, the question is not about showing the ChangeLog changes.
    – Gödel
    Oct 22, 2010 at 19:07
  • D'oh, missed the first line where you said "source diffs."
    – Ken Simon
    Oct 22, 2010 at 19:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .