Why does removing a “metapackage” not remove the dependencies which it installed?
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
add a comment |
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
add a comment |
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
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
deb metapackages
edited Jan 20 at 21:51
tech4him
asked Jan 20 at 21:38
tech4himtech4him
1136
1136
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
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
requireslxqt-core
lxqt-core
requireslxqt-panel
lxqt-panel
depends onlxqt-core
. Actually, this dependency is notRequires
, butRecommends
- 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
Thanks for your answer -- I guess I should have stated my question better. A lot of times it seems thatapt 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
|
show 2 more comments
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.
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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
requireslxqt-core
lxqt-core
requireslxqt-panel
lxqt-panel
depends onlxqt-core
. Actually, this dependency is notRequires
, butRecommends
- 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
Thanks for your answer -- I guess I should have stated my question better. A lot of times it seems thatapt 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
|
show 2 more comments
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
requireslxqt-core
lxqt-core
requireslxqt-panel
lxqt-panel
depends onlxqt-core
. Actually, this dependency is notRequires
, butRecommends
- 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
Thanks for your answer -- I guess I should have stated my question better. A lot of times it seems thatapt 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
|
show 2 more comments
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
requireslxqt-core
lxqt-core
requireslxqt-panel
lxqt-panel
depends onlxqt-core
. Actually, this dependency is notRequires
, butRecommends
- 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
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
requireslxqt-core
lxqt-core
requireslxqt-panel
lxqt-panel
depends onlxqt-core
. Actually, this dependency is notRequires
, butRecommends
- 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
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 thatapt 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
|
show 2 more comments
Thanks for your answer -- I guess I should have stated my question better. A lot of times it seems thatapt 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
|
show 2 more comments
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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