DebianThis forum is for the discussion of Debian Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Every time I apt-get anything, I'm given a huge list of stuff the system thinks I don't need.
But I'm fairly sure I need stuff like kpdf, and kolf (full list below). Some of it I want to keep, the rest I have no idea if I need or not. I know I can set the ones I want to manually installed, but how am I supposed to know? Debian packs have stupid names at the best of times.
I see in your sig you're running Lenny, right? In that case, forget apt-get and use aptitude instead. This is a strong recommendation from the Debian dev's, as aptitude has better ways of detecting and coping with dependencies and problems with that.
Next: forget using the meta-packages. They're nice and easy, but take up space and cause these kind of problems. I recommend the following:
1) use 'aptitude keep-all' to keep all packages on your system
2) update your system with aptitude
3) remove meta-packages by purging them and then (re-)installing the 'real' packages (like gnome-core or xserver-xorg-core)
A little time with Google, and you will find hundreds and hundreds of posts about this. Here's my quick version:
The version of apt-get in Lenny now offers autoremove. This is similar but not identical to aptitude's behavior. Both detect packages that were installed only as a dependency of another package. If the package that caused them to be installed is gone, aptitude will immediately try to remove the dependencies, but apt-get will simply bug you to autoremove them yourself. The thinking is that if you only installed them as a dependency of X, and X is gone, then presumably you don't want or need them any more. (Not everyone agrees with this, but it's certainly not a crazy thought and many people like this behavior. In any case, it's a feature, not a bug - in terms of design.)
The big problem for people new to this is metapackages. A metapackage, for example kde, works as follows. The package itself, kde, is nothing but a name with a huge list of dependencies. When you install it, a huge list of other packages gets dragged in as its dependencies. So when you go to remove one itsy-bitsy little piece of that a month later (say, kate), the metapackage wrapper has to go too (since it depends equally on each item from the huge list of dependencies). After that happens, since everything else from the huge list was installed only as a dependency to kde, apt-get bugs you to autoremove those items and aptitude immediately tries to remove all that stuff.
You can deal with this easily in one of two ways. (1) Don't install meta-packages - especially don't install the ginormous kde or gnome meta-monsters. (2) Install them, do whatever the $%#!* you want with your system, and when apt-get or aptitude bug you, type this simple command:
Code:
aptitude keep-all
This will shut up apt-get and calm down aptitude since they seem to share the same "database" of items that should be removed.
What I don't understand is why removing a metapackage causes apt-get to think it should autoremove dependencies of installed software.
The individual packages that get installed when you ask for a metapackage are all, each and every one of them, dependencies of the metapackage itself. If the metapackage is removed, then the package that they depended on is gone. According to the logic in the process, they should go too. So APT isn't trying to remove dependencies of installed packages. It's trying to remove dependencies of a no-longer-installed package - namely the meta-wrapper itself.
Last edited by Telemachos; 01-19-2009 at 07:02 AM.
The individual packages that get installed when you ask for a metapackage are all, each and every one of them, dependencies of the metapackage itself. If the metapackage is removed, then the package that they depended on is gone. According to the logic in the process, they should go too. So APT isn't trying to remove dependencies of installed packages. It's trying to remove dependencies of a no-longer-installed package - namely the meta-wrapper itself.
I think you misunderstood me. What I meant was that APT should recognise that the although those packages are no longer "necessary" because the meta-package has been removed, they are still needed by other software still installed on the system.
Say:
acmebinary is a dependency of acme-meta-package, which has just been removed from the system.
acmebinary is also a dependency of some-other-package, which is still installed in the system.
Even if acme-meta-package is removed, APT should realise the some-other-package still needs acmebinary, so should not try to autoremove it.
I think you misunderstood me. What I meant was that APT should recognise that the although those packages are no longer "necessary" because the meta-package has been removed, they are still needed by other software still installed on the system.
Say:
acmebinary is a dependency of acme-meta-package, which has just been removed from the system.
acmebinary is also a dependency of some-other-package, which is still installed in the system.
Even if acme-meta-package is removed, APT should realise the some-other-package still needs acmebinary, so should not try to autoremove it.
You tell it to get KDE, it does. Kpdf and libwhatever are some of KDE's dependencies. You remove the KDE meta package. Kpdf and libwhatever are not depended on by anything else, so we can get rid?
No, we want Kpdf, but libwhatever can go. How is apt to know the difference?
I think you misunderstood me. What I meant was that APT should recognise that the although those packages are no longer "necessary" because the meta-package has been removed, they are still needed by other software still installed on the system.
Say:
acmebinary is a dependency of acme-meta-package, which has just been removed from the system.
acmebinary is also a dependency of some-other-package, which is still installed in the system.
Even if acme-meta-package is removed, APT should realise the some-other-package still needs acmebinary, so should not try to autoremove it.
I understood you, but metapackages work the way they do on purpose. Many people, me included, might wish they didn't, but they do. What happens in the case you imagine, I think, is a cascade:
acme-meta-package is gone so acmebinary has to go
some-other-package depends on acmebinary, but acmebinary has to go
a package that some-other-package depends on is going, so some-other-package has to go too
And so on and so on. The first rule is: a package can't stay unless it has all its required dependencies. Everything else follows after that.
If you did it the way you want, you would end up with the reverse problem (I think). The apt tools would end up telling you, "You can't remove foo because bar depends on it."
In any case, there are ways to fix the issues when they come up: explicitly reinstall acmebinary, and then some-other-package and acmebinary can stay on your system happily ever after. So, if you want a metapackage, but not all of it, then just install the bits you do want explicitly. There is also the aptitude keep-all trick I mentioned earlier.
Distribution: Debian /Jessie/Stretch/Sid, Linux Mint DE
Posts: 5,195
Rep:
I think it would have been better is Autoremove had not been added, or that you can enable with a parameter. Disk space is cheap, package sizes are small, and there is no registry slowing down the machine if too many programs are installed.
It should be realized though that it usually doesn't do unreversible harm if you proceed with the autoremove. If you remove too much, simply reinstall the packages you lost. Settings remain on the machine anyway.
I think it would have been better is Autoremove had not been added, or that you can enable with a parameter. Disk space is cheap, package sizes are small, and there is no registry slowing down the machine if too many programs are installed.
It should be realized though that it usually doesn't do unreversible harm if you proceed with the autoremove. If you remove too much, simply reinstall the packages you lost. Settings remain on the machine anyway.
I ignore the Autoremove recommendations.
jlinkels
The windows registry is hierarchical. It's as fast, if not, faster than .*rc files.
I love a good rant on Windows as much as the next man, but don't hate the registry for performance. There's a perfectly good eggs in one basket argument to use instead.
Last edited by BigglesPiP; 01-24-2009 at 09:02 AM.
Distribution: Debian /Jessie/Stretch/Sid, Linux Mint DE
Posts: 5,195
Rep:
Quote:
Originally Posted by BigglesPiP
The windows registry is hierarchical. It's as fast, if not, faster than .*rc files.
I love a good rant on Windows as much as the next man, but don't hate the registry for performance. There's a perfectly good eggs in one basket argument to use instead.
This was not trying to find a rant on Windows, I am seriously convinced that the slowness of Windows is caused by the filling up of the registry. I think we agree that a Windows machine get slower over time, especially if more software is installed, and that it feels like new when we do a clean install.
If I use regedit to search for some key, it takes *seconds* on a fast machine to search thru a registry of a few megabytes. That fits in the assumption that the registry is slow to use. If it is just a bad implementation of the regedit search function, I wonder why MS has not been abale to fix it since 1995.
In Linux, no matter how many packages I have installed (and on some machines that is QUITE a lot) it stays fast as ever.
If I can find an good and true explanation for Windows' degradation over time other than the registry, I will use it in the future. I like a good rant too, but dislike telling untruth.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
apt-get autoremove, LIES!!
