Why does removing a “metapackage” not remove the dependencies which it installed?












1















If I attempt to uninstall a metapackage, apt does not actually remove the metapackage's dependencies, only the "wrapper" itself. Even when running apt autoremove, these subpackages are not listed. I find it confusing that autoremove removes dependencies for most normal packages, but not many metapackages. Why is this?










share|improve this question





























    1















    If I attempt to uninstall a metapackage, apt does not actually remove the metapackage's dependencies, only the "wrapper" itself. Even when running apt autoremove, these subpackages are not listed. I find it confusing that autoremove removes dependencies for most normal packages, but not many metapackages. Why is this?










    share|improve this question



























      1












      1








      1








      If I attempt to uninstall a metapackage, apt does not actually remove the metapackage's dependencies, only the "wrapper" itself. Even when running apt autoremove, these subpackages are not listed. I find it confusing that autoremove removes dependencies for most normal packages, but not many metapackages. Why is this?










      share|improve this question
















      If I attempt to uninstall a metapackage, apt does not actually remove the metapackage's dependencies, only the "wrapper" itself. Even when running apt autoremove, these subpackages are not listed. I find it confusing that autoremove removes dependencies for most normal packages, but not many metapackages. Why is this?







      deb metapackages






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 20 at 21:51







      tech4him

















      asked Jan 20 at 21:38









      tech4himtech4him

      1136




      1136






















          2 Answers
          2






          active

          oldest

          votes


















          1














          Meta-packages are not magic in any regard: the concept "of meta-package" is not part of the APT system - a meta-package is simply a package which doesn't have actual content, just dependencies. So removing them has the same effect as removing a package with actual content that also depends on some other stuff, like a web server application module will require a web server, but when you remove it - the web server should still stay installed.



          That being said, APT keeps track of which packages were automatically installed because another package requested them (like a meta-package requesting "actual" packages, or a web server application module requiring a web server), and once you remove the requiring package APT will suggest you run apt autoremove to get rid of such automatically installed packages.



          The main problem with "meta-packages" as they are used in the Ubuntu operating system is that they depend on a lot of packages, essentially installing a huge selection of software with a single install. When installing so many packages, especially such that are very closely tied together - you can get a lot of cross-dependencies: the meta package requires packages A, B and C for you, but A also depends on B and B (maybe surprisingly) also depends on A. So if you remove the meta-package, only C will get removed.



          As a concrete example, lets consider the LXDE meta-package lubuntu-desktop:





          • lubuntu-desktop requires lxqt-core


          • lxqt-core requires lxqt-panel


          • lxqt-panel depends on lxqt-core. Actually, this dependency is not Requires, but Recommends - but that should be enough for apt to decide not to automatically remove either package.


          The following answers have more details:




          • https://unix.stackexchange.com/a/447957/4323

          • https://unix.stackexchange.com/a/265186/4323






          share|improve this answer


























          • Thanks for your answer -- I guess I should have stated my question better. A lot of times it seems that apt autoremove does not show any of the metapackage's dependencies, while it would if a "normal" package was uninstalled. Any thoughts on that?

            – tech4him
            Jan 20 at 21:53











          • @tech4him: I edited my answer to address your edit

            – Guss
            Jan 20 at 21:55











          • Thanks! It has happened for most alternative desktop environments I've tried to install on a regular (GNOME) base system (xubuntu-desktop, kubuntu-desktop, lubuntu-desktop, etc). To uninstall, I've always had to go back to the Apt log.

            – tech4him
            Jan 20 at 21:57













          • @tech4him - after a bit more research, I have a better answer for you.

            – Guss
            Jan 20 at 22:22











          • That example would also explain why a package with a cyclic dependency, but installed directly (not via metapackage), would still autoremove. When it is below another "layer", those asumptions do not work as well. I'm assuming cyclic dependencies are less common in non-"core" packages such as desktops (but still possible).

            – tech4him
            Jan 20 at 22:40



















          2














          ALL packages installed by the Ubuntu's ubiquity installer are apt-marked 'Manual' (instead of 'Auto), making all those packages ineligible for autoremoval.



          You can still remove them, of course, you just cannot autoremove them.



          The Ubuntu Server, Minimal Image, and Cloud Image installers are not based on ubiquity, and their packages are eligible for autoremoval.



          If you are not familiar with apt-marking, it's simply how apt keeps track of which dependencies were specified by the admin ('Manual'), and which were pulled in as dependencies ('Auto'). See man apt-mark for more information about it.



          The reason for the non-standard Ubiquity behavior is to protect you: Folks modify their desktop systems in all kinds of ways, including ways that require removal of the metapackage. Most users don't usually intend to remove their entire desktop, doing so unexpected can be a rather Significant Emotional Event, so the Ubuntu developers made the change to protect users from their own (unintended) folly. After all, Ubuntu is intended for new and unskilled users, too.



          Folks who want to prune their packages to just what they actually use (we all have tried that at one time or another) will find it much easier to start from the Minimal Image and build up rather than fight the apt-marking to cut down.






          share|improve this answer
























          • That's a very good point, although I was mostly asking about a secondary metapackage install after the system was already installed. Does this answer address this at all, or is it only regarding initial install? It's helpful either way -- I'd just like to clarify.

            – tech4him
            Jan 23 at 23:53






          • 1





            After the installed system is running, then the Ubiquity change no longer applies, of course. All apt actions will be normal: Newly-installed dependencies will be apt-marked 'auto', and will be eligible for auto-removal.

            – user535733
            Jan 24 at 0:15













          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/3.0/"u003ecc by-sa 3.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%2f1111491%2fwhy-does-removing-a-metapackage-not-remove-the-dependencies-which-it-installed%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          1














          Meta-packages are not magic in any regard: the concept "of meta-package" is not part of the APT system - a meta-package is simply a package which doesn't have actual content, just dependencies. So removing them has the same effect as removing a package with actual content that also depends on some other stuff, like a web server application module will require a web server, but when you remove it - the web server should still stay installed.



          That being said, APT keeps track of which packages were automatically installed because another package requested them (like a meta-package requesting "actual" packages, or a web server application module requiring a web server), and once you remove the requiring package APT will suggest you run apt autoremove to get rid of such automatically installed packages.



          The main problem with "meta-packages" as they are used in the Ubuntu operating system is that they depend on a lot of packages, essentially installing a huge selection of software with a single install. When installing so many packages, especially such that are very closely tied together - you can get a lot of cross-dependencies: the meta package requires packages A, B and C for you, but A also depends on B and B (maybe surprisingly) also depends on A. So if you remove the meta-package, only C will get removed.



          As a concrete example, lets consider the LXDE meta-package lubuntu-desktop:





          • lubuntu-desktop requires lxqt-core


          • lxqt-core requires lxqt-panel


          • lxqt-panel depends on lxqt-core. Actually, this dependency is not Requires, but Recommends - but that should be enough for apt to decide not to automatically remove either package.


          The following answers have more details:




          • https://unix.stackexchange.com/a/447957/4323

          • https://unix.stackexchange.com/a/265186/4323






          share|improve this answer


























          • Thanks for your answer -- I guess I should have stated my question better. A lot of times it seems that apt autoremove does not show any of the metapackage's dependencies, while it would if a "normal" package was uninstalled. Any thoughts on that?

            – tech4him
            Jan 20 at 21:53











          • @tech4him: I edited my answer to address your edit

            – Guss
            Jan 20 at 21:55











          • Thanks! It has happened for most alternative desktop environments I've tried to install on a regular (GNOME) base system (xubuntu-desktop, kubuntu-desktop, lubuntu-desktop, etc). To uninstall, I've always had to go back to the Apt log.

            – tech4him
            Jan 20 at 21:57













          • @tech4him - after a bit more research, I have a better answer for you.

            – Guss
            Jan 20 at 22:22











          • That example would also explain why a package with a cyclic dependency, but installed directly (not via metapackage), would still autoremove. When it is below another "layer", those asumptions do not work as well. I'm assuming cyclic dependencies are less common in non-"core" packages such as desktops (but still possible).

            – tech4him
            Jan 20 at 22:40
















          1














          Meta-packages are not magic in any regard: the concept "of meta-package" is not part of the APT system - a meta-package is simply a package which doesn't have actual content, just dependencies. So removing them has the same effect as removing a package with actual content that also depends on some other stuff, like a web server application module will require a web server, but when you remove it - the web server should still stay installed.



          That being said, APT keeps track of which packages were automatically installed because another package requested them (like a meta-package requesting "actual" packages, or a web server application module requiring a web server), and once you remove the requiring package APT will suggest you run apt autoremove to get rid of such automatically installed packages.



          The main problem with "meta-packages" as they are used in the Ubuntu operating system is that they depend on a lot of packages, essentially installing a huge selection of software with a single install. When installing so many packages, especially such that are very closely tied together - you can get a lot of cross-dependencies: the meta package requires packages A, B and C for you, but A also depends on B and B (maybe surprisingly) also depends on A. So if you remove the meta-package, only C will get removed.



          As a concrete example, lets consider the LXDE meta-package lubuntu-desktop:





          • lubuntu-desktop requires lxqt-core


          • lxqt-core requires lxqt-panel


          • lxqt-panel depends on lxqt-core. Actually, this dependency is not Requires, but Recommends - but that should be enough for apt to decide not to automatically remove either package.


          The following answers have more details:




          • https://unix.stackexchange.com/a/447957/4323

          • https://unix.stackexchange.com/a/265186/4323






          share|improve this answer


























          • Thanks for your answer -- I guess I should have stated my question better. A lot of times it seems that apt autoremove does not show any of the metapackage's dependencies, while it would if a "normal" package was uninstalled. Any thoughts on that?

            – tech4him
            Jan 20 at 21:53











          • @tech4him: I edited my answer to address your edit

            – Guss
            Jan 20 at 21:55











          • Thanks! It has happened for most alternative desktop environments I've tried to install on a regular (GNOME) base system (xubuntu-desktop, kubuntu-desktop, lubuntu-desktop, etc). To uninstall, I've always had to go back to the Apt log.

            – tech4him
            Jan 20 at 21:57













          • @tech4him - after a bit more research, I have a better answer for you.

            – Guss
            Jan 20 at 22:22











          • That example would also explain why a package with a cyclic dependency, but installed directly (not via metapackage), would still autoremove. When it is below another "layer", those asumptions do not work as well. I'm assuming cyclic dependencies are less common in non-"core" packages such as desktops (but still possible).

            – tech4him
            Jan 20 at 22:40














          1












          1








          1







          Meta-packages are not magic in any regard: the concept "of meta-package" is not part of the APT system - a meta-package is simply a package which doesn't have actual content, just dependencies. So removing them has the same effect as removing a package with actual content that also depends on some other stuff, like a web server application module will require a web server, but when you remove it - the web server should still stay installed.



          That being said, APT keeps track of which packages were automatically installed because another package requested them (like a meta-package requesting "actual" packages, or a web server application module requiring a web server), and once you remove the requiring package APT will suggest you run apt autoremove to get rid of such automatically installed packages.



          The main problem with "meta-packages" as they are used in the Ubuntu operating system is that they depend on a lot of packages, essentially installing a huge selection of software with a single install. When installing so many packages, especially such that are very closely tied together - you can get a lot of cross-dependencies: the meta package requires packages A, B and C for you, but A also depends on B and B (maybe surprisingly) also depends on A. So if you remove the meta-package, only C will get removed.



          As a concrete example, lets consider the LXDE meta-package lubuntu-desktop:





          • lubuntu-desktop requires lxqt-core


          • lxqt-core requires lxqt-panel


          • lxqt-panel depends on lxqt-core. Actually, this dependency is not Requires, but Recommends - but that should be enough for apt to decide not to automatically remove either package.


          The following answers have more details:




          • https://unix.stackexchange.com/a/447957/4323

          • https://unix.stackexchange.com/a/265186/4323






          share|improve this answer















          Meta-packages are not magic in any regard: the concept "of meta-package" is not part of the APT system - a meta-package is simply a package which doesn't have actual content, just dependencies. So removing them has the same effect as removing a package with actual content that also depends on some other stuff, like a web server application module will require a web server, but when you remove it - the web server should still stay installed.



          That being said, APT keeps track of which packages were automatically installed because another package requested them (like a meta-package requesting "actual" packages, or a web server application module requiring a web server), and once you remove the requiring package APT will suggest you run apt autoremove to get rid of such automatically installed packages.



          The main problem with "meta-packages" as they are used in the Ubuntu operating system is that they depend on a lot of packages, essentially installing a huge selection of software with a single install. When installing so many packages, especially such that are very closely tied together - you can get a lot of cross-dependencies: the meta package requires packages A, B and C for you, but A also depends on B and B (maybe surprisingly) also depends on A. So if you remove the meta-package, only C will get removed.



          As a concrete example, lets consider the LXDE meta-package lubuntu-desktop:





          • lubuntu-desktop requires lxqt-core


          • lxqt-core requires lxqt-panel


          • lxqt-panel depends on lxqt-core. Actually, this dependency is not Requires, but Recommends - but that should be enough for apt to decide not to automatically remove either package.


          The following answers have more details:




          • https://unix.stackexchange.com/a/447957/4323

          • https://unix.stackexchange.com/a/265186/4323







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Jan 21 at 6:15

























          answered Jan 20 at 21:47









          GussGuss

          2,40822235




          2,40822235













          • Thanks for your answer -- I guess I should have stated my question better. A lot of times it seems that apt autoremove does not show any of the metapackage's dependencies, while it would if a "normal" package was uninstalled. Any thoughts on that?

            – tech4him
            Jan 20 at 21:53











          • @tech4him: I edited my answer to address your edit

            – Guss
            Jan 20 at 21:55











          • Thanks! It has happened for most alternative desktop environments I've tried to install on a regular (GNOME) base system (xubuntu-desktop, kubuntu-desktop, lubuntu-desktop, etc). To uninstall, I've always had to go back to the Apt log.

            – tech4him
            Jan 20 at 21:57













          • @tech4him - after a bit more research, I have a better answer for you.

            – Guss
            Jan 20 at 22:22











          • That example would also explain why a package with a cyclic dependency, but installed directly (not via metapackage), would still autoremove. When it is below another "layer", those asumptions do not work as well. I'm assuming cyclic dependencies are less common in non-"core" packages such as desktops (but still possible).

            – tech4him
            Jan 20 at 22:40



















          • Thanks for your answer -- I guess I should have stated my question better. A lot of times it seems that apt autoremove does not show any of the metapackage's dependencies, while it would if a "normal" package was uninstalled. Any thoughts on that?

            – tech4him
            Jan 20 at 21:53











          • @tech4him: I edited my answer to address your edit

            – Guss
            Jan 20 at 21:55











          • Thanks! It has happened for most alternative desktop environments I've tried to install on a regular (GNOME) base system (xubuntu-desktop, kubuntu-desktop, lubuntu-desktop, etc). To uninstall, I've always had to go back to the Apt log.

            – tech4him
            Jan 20 at 21:57













          • @tech4him - after a bit more research, I have a better answer for you.

            – Guss
            Jan 20 at 22:22











          • That example would also explain why a package with a cyclic dependency, but installed directly (not via metapackage), would still autoremove. When it is below another "layer", those asumptions do not work as well. I'm assuming cyclic dependencies are less common in non-"core" packages such as desktops (but still possible).

            – tech4him
            Jan 20 at 22:40

















          Thanks for your answer -- I guess I should have stated my question better. A lot of times it seems that apt autoremove does not show any of the metapackage's dependencies, while it would if a "normal" package was uninstalled. Any thoughts on that?

          – tech4him
          Jan 20 at 21:53





          Thanks for your answer -- I guess I should have stated my question better. A lot of times it seems that apt autoremove does not show any of the metapackage's dependencies, while it would if a "normal" package was uninstalled. Any thoughts on that?

          – tech4him
          Jan 20 at 21:53













          @tech4him: I edited my answer to address your edit

          – Guss
          Jan 20 at 21:55





          @tech4him: I edited my answer to address your edit

          – Guss
          Jan 20 at 21:55













          Thanks! It has happened for most alternative desktop environments I've tried to install on a regular (GNOME) base system (xubuntu-desktop, kubuntu-desktop, lubuntu-desktop, etc). To uninstall, I've always had to go back to the Apt log.

          – tech4him
          Jan 20 at 21:57







          Thanks! It has happened for most alternative desktop environments I've tried to install on a regular (GNOME) base system (xubuntu-desktop, kubuntu-desktop, lubuntu-desktop, etc). To uninstall, I've always had to go back to the Apt log.

          – tech4him
          Jan 20 at 21:57















          @tech4him - after a bit more research, I have a better answer for you.

          – Guss
          Jan 20 at 22:22





          @tech4him - after a bit more research, I have a better answer for you.

          – Guss
          Jan 20 at 22:22













          That example would also explain why a package with a cyclic dependency, but installed directly (not via metapackage), would still autoremove. When it is below another "layer", those asumptions do not work as well. I'm assuming cyclic dependencies are less common in non-"core" packages such as desktops (but still possible).

          – tech4him
          Jan 20 at 22:40





          That example would also explain why a package with a cyclic dependency, but installed directly (not via metapackage), would still autoremove. When it is below another "layer", those asumptions do not work as well. I'm assuming cyclic dependencies are less common in non-"core" packages such as desktops (but still possible).

          – tech4him
          Jan 20 at 22:40













          2














          ALL packages installed by the Ubuntu's ubiquity installer are apt-marked 'Manual' (instead of 'Auto), making all those packages ineligible for autoremoval.



          You can still remove them, of course, you just cannot autoremove them.



          The Ubuntu Server, Minimal Image, and Cloud Image installers are not based on ubiquity, and their packages are eligible for autoremoval.



          If you are not familiar with apt-marking, it's simply how apt keeps track of which dependencies were specified by the admin ('Manual'), and which were pulled in as dependencies ('Auto'). See man apt-mark for more information about it.



          The reason for the non-standard Ubiquity behavior is to protect you: Folks modify their desktop systems in all kinds of ways, including ways that require removal of the metapackage. Most users don't usually intend to remove their entire desktop, doing so unexpected can be a rather Significant Emotional Event, so the Ubuntu developers made the change to protect users from their own (unintended) folly. After all, Ubuntu is intended for new and unskilled users, too.



          Folks who want to prune their packages to just what they actually use (we all have tried that at one time or another) will find it much easier to start from the Minimal Image and build up rather than fight the apt-marking to cut down.






          share|improve this answer
























          • That's a very good point, although I was mostly asking about a secondary metapackage install after the system was already installed. Does this answer address this at all, or is it only regarding initial install? It's helpful either way -- I'd just like to clarify.

            – tech4him
            Jan 23 at 23:53






          • 1





            After the installed system is running, then the Ubiquity change no longer applies, of course. All apt actions will be normal: Newly-installed dependencies will be apt-marked 'auto', and will be eligible for auto-removal.

            – user535733
            Jan 24 at 0:15


















          2














          ALL packages installed by the Ubuntu's ubiquity installer are apt-marked 'Manual' (instead of 'Auto), making all those packages ineligible for autoremoval.



          You can still remove them, of course, you just cannot autoremove them.



          The Ubuntu Server, Minimal Image, and Cloud Image installers are not based on ubiquity, and their packages are eligible for autoremoval.



          If you are not familiar with apt-marking, it's simply how apt keeps track of which dependencies were specified by the admin ('Manual'), and which were pulled in as dependencies ('Auto'). See man apt-mark for more information about it.



          The reason for the non-standard Ubiquity behavior is to protect you: Folks modify their desktop systems in all kinds of ways, including ways that require removal of the metapackage. Most users don't usually intend to remove their entire desktop, doing so unexpected can be a rather Significant Emotional Event, so the Ubuntu developers made the change to protect users from their own (unintended) folly. After all, Ubuntu is intended for new and unskilled users, too.



          Folks who want to prune their packages to just what they actually use (we all have tried that at one time or another) will find it much easier to start from the Minimal Image and build up rather than fight the apt-marking to cut down.






          share|improve this answer
























          • That's a very good point, although I was mostly asking about a secondary metapackage install after the system was already installed. Does this answer address this at all, or is it only regarding initial install? It's helpful either way -- I'd just like to clarify.

            – tech4him
            Jan 23 at 23:53






          • 1





            After the installed system is running, then the Ubiquity change no longer applies, of course. All apt actions will be normal: Newly-installed dependencies will be apt-marked 'auto', and will be eligible for auto-removal.

            – user535733
            Jan 24 at 0:15
















          2












          2








          2







          ALL packages installed by the Ubuntu's ubiquity installer are apt-marked 'Manual' (instead of 'Auto), making all those packages ineligible for autoremoval.



          You can still remove them, of course, you just cannot autoremove them.



          The Ubuntu Server, Minimal Image, and Cloud Image installers are not based on ubiquity, and their packages are eligible for autoremoval.



          If you are not familiar with apt-marking, it's simply how apt keeps track of which dependencies were specified by the admin ('Manual'), and which were pulled in as dependencies ('Auto'). See man apt-mark for more information about it.



          The reason for the non-standard Ubiquity behavior is to protect you: Folks modify their desktop systems in all kinds of ways, including ways that require removal of the metapackage. Most users don't usually intend to remove their entire desktop, doing so unexpected can be a rather Significant Emotional Event, so the Ubuntu developers made the change to protect users from their own (unintended) folly. After all, Ubuntu is intended for new and unskilled users, too.



          Folks who want to prune their packages to just what they actually use (we all have tried that at one time or another) will find it much easier to start from the Minimal Image and build up rather than fight the apt-marking to cut down.






          share|improve this answer













          ALL packages installed by the Ubuntu's ubiquity installer are apt-marked 'Manual' (instead of 'Auto), making all those packages ineligible for autoremoval.



          You can still remove them, of course, you just cannot autoremove them.



          The Ubuntu Server, Minimal Image, and Cloud Image installers are not based on ubiquity, and their packages are eligible for autoremoval.



          If you are not familiar with apt-marking, it's simply how apt keeps track of which dependencies were specified by the admin ('Manual'), and which were pulled in as dependencies ('Auto'). See man apt-mark for more information about it.



          The reason for the non-standard Ubiquity behavior is to protect you: Folks modify their desktop systems in all kinds of ways, including ways that require removal of the metapackage. Most users don't usually intend to remove their entire desktop, doing so unexpected can be a rather Significant Emotional Event, so the Ubuntu developers made the change to protect users from their own (unintended) folly. After all, Ubuntu is intended for new and unskilled users, too.



          Folks who want to prune their packages to just what they actually use (we all have tried that at one time or another) will find it much easier to start from the Minimal Image and build up rather than fight the apt-marking to cut down.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 21 at 6:59









          user535733user535733

          8,57622943




          8,57622943













          • That's a very good point, although I was mostly asking about a secondary metapackage install after the system was already installed. Does this answer address this at all, or is it only regarding initial install? It's helpful either way -- I'd just like to clarify.

            – tech4him
            Jan 23 at 23:53






          • 1





            After the installed system is running, then the Ubiquity change no longer applies, of course. All apt actions will be normal: Newly-installed dependencies will be apt-marked 'auto', and will be eligible for auto-removal.

            – user535733
            Jan 24 at 0:15





















          • That's a very good point, although I was mostly asking about a secondary metapackage install after the system was already installed. Does this answer address this at all, or is it only regarding initial install? It's helpful either way -- I'd just like to clarify.

            – tech4him
            Jan 23 at 23:53






          • 1





            After the installed system is running, then the Ubiquity change no longer applies, of course. All apt actions will be normal: Newly-installed dependencies will be apt-marked 'auto', and will be eligible for auto-removal.

            – user535733
            Jan 24 at 0:15



















          That's a very good point, although I was mostly asking about a secondary metapackage install after the system was already installed. Does this answer address this at all, or is it only regarding initial install? It's helpful either way -- I'd just like to clarify.

          – tech4him
          Jan 23 at 23:53





          That's a very good point, although I was mostly asking about a secondary metapackage install after the system was already installed. Does this answer address this at all, or is it only regarding initial install? It's helpful either way -- I'd just like to clarify.

          – tech4him
          Jan 23 at 23:53




          1




          1





          After the installed system is running, then the Ubiquity change no longer applies, of course. All apt actions will be normal: Newly-installed dependencies will be apt-marked 'auto', and will be eligible for auto-removal.

          – user535733
          Jan 24 at 0:15







          After the installed system is running, then the Ubiquity change no longer applies, of course. All apt actions will be normal: Newly-installed dependencies will be apt-marked 'auto', and will be eligible for auto-removal.

          – user535733
          Jan 24 at 0:15




















          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%2f1111491%2fwhy-does-removing-a-metapackage-not-remove-the-dependencies-which-it-installed%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

          Biblatex bibliography style without URLs when DOI exists (in Overleaf with Zotero bibliography)

          ComboBox Display Member on multiple fields

          Is it possible to collect Nectar points via Trainline?