How can different packages have identical source code?Error :: You must put some 'source' URIs in your sources.listHow to use 'apt' to get source code and then do separate compileTrouble creating library packageHow to have Debian packaging generate two packages given an upstream source archive?How to maintain a patched upstream packageHow to use 'apt' to get source code and then do separate compileHow to set version numbers and package file names via dpkg-buildpackge for automated builds on a build server?How to purge *all* Unity packages?Using sudo apt-get install, why no source code?How to create a debian/control file that differs based on Ubuntu release?How does the update process work for different install methods?

Get a character at a specified location

I noticed an error in a graded exam during office hours. Should I give the student the lower grade?

Would a warhorse allow its rider to approach a Dragon at all?

Are there any proofs of exponnential lower bound time complexity

What type of interpreter were most 8-bit BASIC implementations?

Translate the French quote "Il n’y a pas d'amour, il n’y a que des preuves d’amour" to English?

A sad duck with TikZ (or TikZducks?)

Is there a reason to have 2 or more witnesses at the same time during the current impeachment hearings

Short story from the 70s(?) about aliens/angels destroying humankind, from the point of view of a priest/pastor

Will Curiosity and the Mars 2020 rover be able to communicate with each other via a Mars orbiter?

Why does this process map every fraction to the golden ratio?

Using a sealant to stop a toilet tank leak

Is there a difference between “When you are reduced to 0 hit points” and “when you would be reduced to 0 hit points”?

Is Earth's Surface "In orbit"?

Quantum circuits explain algorithms, why didn't classical circuits?

Large products with glass doors

Can Deck of Illusion illusions do non-harmful actions?

Balancing empathy and deferring to the syllabus in teaching responsibilities

Is a geodesic in the 4d spacetime still a geodesic after projection onto the 3d space?

Is CCing the manager in first e-mail regarding urgent matter considered escalation?

Perfect pitch on only one instrument?

Patent Agreement in Order to Graduate

What instructions should I give to an untrained passenger for Hand propping Cessna 172N as a pilot?

My PhD defense is next week and I am having negative thoughts about my work and knowledge. Any advice on how to tackle this?



How can different packages have identical source code?


Error :: You must put some 'source' URIs in your sources.listHow to use 'apt' to get source code and then do separate compileTrouble creating library packageHow to have Debian packaging generate two packages given an upstream source archive?How to maintain a patched upstream packageHow to use 'apt' to get source code and then do separate compileHow to set version numbers and package file names via dpkg-buildpackge for automated builds on a build server?How to purge *all* Unity packages?Using sudo apt-get install, why no source code?How to create a debian/control file that differs based on Ubuntu release?How does the update process work for different install methods?






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty
margin-bottom:0;









39


















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










share|improve this question

































    39


















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










    share|improve this question





























      39













      39









      39


      5






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










      share|improve this question
















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







      package-management software-installation packaging






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Oct 17 at 3:42







      Elias

















      asked Oct 15 at 12:58









      EliasElias

      1,2176 silver badges20 bronze badges




      1,2176 silver badges20 bronze badges























          3 Answers
          3






          active

          oldest

          votes


















          41



















          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.






          share|improve this answer























          • 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 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 at 14:00







          • 1





            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 at 0:20


















          13



















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







          share|improve this answer



































            2



















            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.






            share|improve this answer























            • 4





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

              – Stephen Kitt
              Oct 16 at 10:08






            • 1





              @StephenKitt Let's not be too literal... the point of the analogy remains.

              – Lightness Races with Monica
              Oct 16 at 11:50













            Your Answer








            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "89"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader:
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/4.0/"u003ecc by-sa 4.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            ,
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );














            draft saved

            draft discarded
















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1181089%2fhow-can-different-packages-have-identical-source-code%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown


























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            41



















            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.






            share|improve this answer























            • 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 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 at 14:00







            • 1





              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 at 0:20















            41



















            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.






            share|improve this answer























            • 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 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 at 14:00







            • 1





              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 at 0:20













            41















            41











            41









            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.






            share|improve this answer
















            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.







            share|improve this answer















            share|improve this answer




            share|improve this answer








            edited Oct 15 at 17:49









            N0rbert

            35.6k10 gold badges81 silver badges167 bronze badges




            35.6k10 gold badges81 silver badges167 bronze badges










            answered Oct 15 at 13:37









            Thomas WardThomas Ward

            52.7k24 gold badges132 silver badges190 bronze badges




            52.7k24 gold badges132 silver badges190 bronze badges










            • 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 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 at 14:00







            • 1





              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 at 0:20












            • 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 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 at 14:00







            • 1





              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 at 0:20







            1




            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 at 13:56






            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 at 13:56





            3




            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 at 14:00






            @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 at 14:00





            1




            1





            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 at 0:20





            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 at 0:20













            13



















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







            share|improve this answer
































              13



















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







              share|improve this answer






























                13















                13











                13









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







                share|improve this answer
















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








                share|improve this answer















                share|improve this answer




                share|improve this answer








                edited Oct 15 at 13:58

























                answered Oct 15 at 13:37









                Eliah KaganEliah Kagan

                95.3k25 gold badges256 silver badges410 bronze badges




                95.3k25 gold badges256 silver badges410 bronze badges
























                    2



















                    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.






                    share|improve this answer























                    • 4





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

                      – Stephen Kitt
                      Oct 16 at 10:08






                    • 1





                      @StephenKitt Let's not be too literal... the point of the analogy remains.

                      – Lightness Races with Monica
                      Oct 16 at 11:50
















                    2



















                    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.






                    share|improve this answer























                    • 4





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

                      – Stephen Kitt
                      Oct 16 at 10:08






                    • 1





                      @StephenKitt Let's not be too literal... the point of the analogy remains.

                      – Lightness Races with Monica
                      Oct 16 at 11:50














                    2















                    2











                    2









                    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.






                    share|improve this answer
















                    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.







                    share|improve this answer















                    share|improve this answer




                    share|improve this answer








                    edited Oct 16 at 11:51

























                    answered Oct 15 at 23:46









                    Lightness Races with MonicaLightness Races with Monica

                    4183 silver badges10 bronze badges




                    4183 silver badges10 bronze badges










                    • 4





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

                      – Stephen Kitt
                      Oct 16 at 10:08






                    • 1





                      @StephenKitt Let's not be too literal... the point of the analogy remains.

                      – Lightness Races with Monica
                      Oct 16 at 11:50













                    • 4





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

                      – Stephen Kitt
                      Oct 16 at 10:08






                    • 1





                      @StephenKitt Let's not be too literal... the point of the analogy remains.

                      – Lightness Races with Monica
                      Oct 16 at 11:50








                    4




                    4





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

                    – Stephen Kitt
                    Oct 16 at 10:08





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

                    – Stephen Kitt
                    Oct 16 at 10:08




                    1




                    1





                    @StephenKitt Let's not be too literal... the point of the analogy remains.

                    – Lightness Races with Monica
                    Oct 16 at 11:50






                    @StephenKitt Let's not be too literal... the point of the analogy remains.

                    – Lightness Races with Monica
                    Oct 16 at 11:50



















                    draft saved

                    draft discarded















































                    Thanks for contributing an answer to Ask Ubuntu!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid


                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1181089%2fhow-can-different-packages-have-identical-source-code%23new-answer', 'question_page');

                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown









                    Popular posts from this blog

                    Canceling a color specificationRandomly assigning color to Graphics3D objects?Default color for Filling in Mathematica 9Coloring specific elements of sets with a prime modified order in an array plotHow to pick a color differing significantly from the colors already in a given color list?Detection of the text colorColor numbers based on their valueCan color schemes for use with ColorData include opacity specification?My dynamic color schemes

                    Invision Community Contents History See also References External links Navigation menuProprietaryinvisioncommunity.comIPS Community ForumsIPS Community Forumsthis blog entry"License Changes, IP.Board 3.4, and the Future""Interview -- Matt Mecham of Ibforums""CEO Invision Power Board, Matt Mecham Is a Liar, Thief!"IPB License Explanation 1.3, 1.3.1, 2.0, and 2.1ArchivedSecurity Fixes, Updates And Enhancements For IPB 1.3.1Archived"New Demo Accounts - Invision Power Services"the original"New Default Skin"the original"Invision Power Board 3.0.0 and Applications Released"the original"Archived copy"the original"Perpetual licenses being done away with""Release Notes - Invision Power Services""Introducing: IPS Community Suite 4!"Invision Community Release Notes

                    199年 目錄 大件事 到箇年出世嗰人 到箇年死嗰人 節慶、風俗習慣 導覽選單