I recently learned how easy it is to get the source code for any given package using apt-get source so that I can get the source code, make changes and install my own modified version of any package. This is great!

Until today I was assuming that each package would have its own source code, and that different packages would have different source code.

However, now I just discovered that different packages can have identical source code. Here follows an example of that:

The following 4 packages seem to have identical source code:


All four of them are installed on my Ubuntu 19.04 computer. Doing apt-get source gir1.2-mutter-4 gives exactly the same result as apt-get source libmutter-4-0, and also for the mutter and mutter-common packages.

Here is how I checked it:

mkdir a
cd a
apt-get source gir1.2-mutter-4
cd ..
mkdir b
cd b
apt-get source libmutter-4-0
cd ..
diff -r a b

The recursive diff on the last line above gives no output, showing that the directories have identical contents.

Now to my question: How can different packages have identical source code?

Assuming that this is intended and not some kind of error, what is the difference between the packages and how can I see that difference?

Could it be that the packages are different in the way the source code is configured and compiled, e.g. different parts of the code are included in the different packages? If so, where can I find information about how to configure each package?

Edit: forgot to add that if you want to test this, to make apt-get source work properly you may first need to enable it using software-properties-gtk as described here: https://askubuntu.com/a/857433/874649

Edit 2: thanks for the excellent answers! I also found this helpful https://askubuntu.com/a/246721/874649 -- about the apt-get build-dep and dpkg-buildpackage commands that are very useful. After modifying source code for a source package, dpkg-buildpackage -us -uc can be used to build new .deb file(s) that can be used to install the modified program(s).

3 Answers 3


You're confusing built binary packages with the underlying source code/package that the packages were built from.

The packages you're referring to are all built from the same source code/package, mutter. You can find that easily by going to packages.ubuntu.com, searching the package you're looking at, and then refer to the "Source package" it refers to. Which in this case is mutter:

enter image description here

From there, however, we can check the Launchpad page for Mutter's source package and see that it builds a multitude of binary packages (built compiled source code, etc. for installation):

enter image description here

These descriptions describe what each package contains/installs. Focusing on the 4 packages you indicated, and using these descriptions:

  • gir1.2-mutter-4 - GObject introspection data for Mutter (used by gir and GObject as libraries/data for Mutter and GObject interaction)
  • libmutter-4-0 - The underlying library for the Mutter window manager. (Used for plugin development, development and compiling Mutter integrations, etc. usually)
  • mutter - the actual Mutter Window Manager that uses GNOME's Window Manager Library (which is why GObject is needed)
  • mutter-common - Shared Files for Mutter - usually default configuration options or items which are common to all the packages built from the source package.

What you're seeing in your package list are the built packages which originate from the same source code - each package is different items being installed after build/compile time and are used differently for different things. You can see what's in the packages themselves by downloading the individual packages and then accessing them with p7zip or the in-built Archive Manager in Ubuntu and see the differences of what each package contains that way. This said, they all originate from the same source code - they just contain different items that're being installed to the system.

  • 1
    Thank you, this was most enlightening! Ideally I would have liked some command-line way of getting the building instructions for each package, now that I have learned that the source code package itself does not contain that info. Something like "apt-get build-instructions mutter" -- do you know if there is something like that? To get the list of commands needed to actually build the binary package, e.g. first run configure and then make, precisely how to do that to produce the given binary package.
    – Elias
    Oct 15, 2019 at 13:56
  • 3
    @Elias that's stored in the debian/rules file of the source package. There's no way to get that from the command line without delving into the code itself. And if you're really interested into how the build system works, you need to understand much wider concepts - Ubuntu packaging (packaging.ubuntu.com/html) and Debian Packaging (wiki.debian.org/Packaging) as well - because there's concepts in that which are crucial to understanding how the binaries themselves are created and compiled and then actually packaged for installation in the binary packages that get installed
    – Thomas Ward
    Oct 15, 2019 at 14:00
  • 2
    Very Good answer! In non-tech terms, you could think about the sources like a 'book of plans' to build a kitchen, and the packages as the actual creation of one part of the kitchen based on those plans.
    – Cinderhaze
    Oct 17, 2019 at 0:20

Source packages and binary packages exist separately. Each source package may have multiple binary packages associated with it. This is to say that more than one binary package may be built from the same source package.

One of the common ways this happens is that you have a program, a library that the program uses to do much of its work, and the header files used to compile it and other (perhaps future) programs that use that library. They are all developed and maintained in the same source tree, which is used, with or without Debian or Ubuntu patches, to generate a source package. Then that source package is used to build separate binary packages for the program, the library, and the headers.

That's what you have here (with some other binary packages as well). You've specified different binary packages in your apt source command, but the command is downloading and unpacking the same source package.

This happens because, when you pass the a package name to apt source but there is no source package with that name, it treats it as the name of a binary package and assumes you want that binary package's corresponding source package.

On the main Ubuntu page on Launchpad, you can search for packages. Launchpad displays information about source packages (whilst Ubuntu Packages Search displays information about binary packages). If you search for mutter, then as Thomas Ward has said you'll find the Launchpad page for the mutter source package in Ubuntu. This is one good way to see which binary packages correspond to a source package. Near the top of that page, it says:

mutter package in Ubuntu

gir1.2-mutter-4: GObject introspection data for Mutter
libmutter-4-0: window manager library from the Mutter window manager
libmutter-4-0-dbgsym: No summary available for libmutter-4-0-dbgsym in ubuntu eoan.
libmutter-4-dev: Development files for the Mutter window manager
mutter: Example window manager using GNOME's window manager library
mutter-common: shared files for the Mutter window manager
mutter-dbgsym: debug symbols for mutter

Even when a binary package does not have the same name as the source package from which it is built, you can usually find that source package by searching on Launchpad for the binary package.

You can often know what the relationship is between a binary package and the source package used to build it by inspecting the name of the binary package:

  • Binary package names that start with lib usually provide libraries of code that can be used by multiple programs (including future programs).

  • Those that end in -dev provide header files, which facilitate the compilation of source code that uses the libraries.

  • Those that end in -dbg or -dbgsym provide debug symbols (so even though libmutter-4-0-dbgsym doesn't currently show a summary, we know it's a debug symbol package).

  • Those that end in -common tend to provide files, often data files, that reside in /usr/share. Such files are sometimes effectively code, just in a static and declarative form, but they may also provide interface translations into natural (i.e. human) languages. There's not really much limitation on what can go in such a package.

    For mutter, the -common binary package (in recent versions) contains schemas, key bindings, and documentation. One benefit of -common packages is that, because they don't typically contain any native machine code, the same package file is usually applies to all architectures. (Strictly speaking, this is the one key requirement for files placed in /usr/share.)


Take the following ingredients:

  • Onions
  • Tomatoes
  • Bread
  • Olives

Can you only make one dish from these? No. What you end up eating depends on the recipe.

Each package contains a recipe. It tells the computer what to do with the ingredients, to produce the requested dish(es).

It's reasonable and normal for some packages to share a list of ingredients. Of course, in this context, you'd expect that only to be the case in practice when said packages originate from the same project.

  • 6
    In the case of packages however, you have a single recipe (the source package and its build instructions) which produces multiple dishes (the binary packages). Oct 16, 2019 at 10:08
  • 1
    @StephenKitt Let's not be too literal... the point of the analogy remains. Oct 16, 2019 at 11:50

You must log in to answer this question.

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