Mfcttrf

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:

gir1.2-mutter-4
libmutter-4-0
mutter
mutter-common

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

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:

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):

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.

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.