Is this apt-get autoremove operation safe?
 

I have just upgraded to Wheezy and apt-get autoremove is saying there are the following packages which may be safely removed. I have kde 4.7.4 installed.

Ouch! No , not when it wants to remove that many packages and things like hal, and all the python stuff.

Try running apt-get -f install
or Open Synaptic and see what it says in either Obsolete or Autoremovable, something needs to be installed that was some how removed.

I find the safest thing to do is disable autoremove in apt.conf.

@ Reply
 

Hi edbarx,

Yes it is safe to use apt-get autoremove option. It removes the packages that are no longer needed so you can use this option.

@ craigevil

As I can see from the man apt-get page it says:

Could you please explain why this option cannot be used? I mean is there a specific reason?

As the name suggests, apt-get AUTOremove is an automated operation where the system takes its "best guess" what you are trying to achieve. It should not be used as a substitute for common sense system administration.

Since you are new to Debian Testing you should definitely do some basic reading first. It is actually a fairly common situation in Testing that the user must go on the forum/mailing-lists to understand a particular update situation.

The safest thing to do is not use the (completely optional!!) apt-get autoremove until you understand the situation. Personally at this stage my next step would be to use tasksel to make sure you have installed the correct metapackages (I'm guessing you want Desktop Environment, right?) to avoid the situation of autoremove removing wanted packages.

DISCLAIMER: I am not a Testing user myself, and I know there are some pretty knowledgable Testing users here, so take my advice with a grain of salt. :)

Wheezy is not misbehaving. I already did some reading to learn about the listed packages for removal. Whenever there is a big list of packages for removal, it is always safer to be on the side of caution. However, even if I remove the packages, I can still take a note of packages' names, save them to a file and use:
I didn't continue with the removal operation.

@ Reply
 

As far as I know if you use apt-get install to install the stuff on your system then apt-get autoremove should not hurt. It might create a problem if you do install stuff explicitly (that is without using apt-get install).

In that case apt-get autoremove might make a mistake as it will not be aware about the packages dependency of the package that you have installed explicitly.

If as you say you went from Squeeze to Wheezy, then a lot of stuff might just have been obsoleted. :)

Take the time and do a web search for "Debian meta-package problem", I think you will find plenty of explanations.
In short, Debian developers create meta-packages that don't contain any software, but have a lot of dependencies. This is used, for example, to install a complete desktop system with a single apt-get command, for example apt-get install gnome. In this case the package doesn't contain Gnome, but is dependent on all packages the Debian developers think that should be part of a Gnome install.
The problem with this approach: If you (or an update) removes a package that is part of this dependency list the auto-remove function wants to remove all other packages in the dependency list, leaving you with a system without working desktop (and sometimes even with a completely broken system).
apt-get autoremove is a dangerous weapon, use it with care (and edbarx has done that, rather ask than mindlessly confirm to rip out half of the system, relying on an automatic function).

Having said that, I thank Pat Volkerding for this one great system without automatic dependency resolution.

@ Reply
 

I did some web search and came across this: http://administratosphere.wordpress....et-autoremove/

I can make out the following points from this link:

1. When you install a package using: system consider it as a package which user wants to install. The packages which will be required as a dependency to this package will be considered as automatic package installation. So basically the initial command that has been given to install a package is explicit or manual install.

2. As you said about meta-package it is a package that contains all the dependency and it is not a software in itself. I found it to be like a shopping list (read somewhere). So basically meta-package is not a dish itself but ingredients that will be used in a dish.

Questions that is still bothering me is the later explanation in that article. Let us assume that I have installed gnome using:

Now, this will install all the packages that are required by gnome. Now I went ahead and did a search of packages that were installed as part of dependency resolution during gnome installation using:

And I planned to remove say gnome office using explicit command:

When I did the above and then ran:

It came up stating that there is one package to remove named simple-scan. Now this package is used basically for providing scanning functionality for documents / images. Since gnome office has been removed this application system think is no longer required and which is correct.

Thing that is still confusing me is how system calculates which things to include/exclude in autoremove option.

Did you do that on Ubuntu or on Debian? AFAIK, those both distributions handle the marking of automatically installed packages differently, Ubuntu handles it in a way that is more newbie friendly by marking those dependencies as manually installed to prevent newbies from accidentally delete half the system with apt-get, while Debian assumes that you are knowing what you do when you are playing with the package manager.

I am certainly no expert on running Debian testing. I do have, however, this install of it which I have used for about 2 years as my production OS.

I wouldn't use the autoremove command if I were you.

Just pulled it up to take a look at it and in about 15 seconds of glancing at it only picked out to packages that are currently in use.

Admittedly it would not be a disaster if I removed lobrhythmbox-core5 or rhythmbox-data. Rhythmbox depends on both of these so I think it may suffer but could be reinstalled easily.

I do have a lot of experience with Ubuntu testing releases. Using auto remove on them is a very good way to break your system.

This is a command that is intended for stable releases.

You could easily go to synaptic and go through the list there. Select one at a time and hit apply. It will offer you a chance to back out. See what all is being removed.

You can set your preferences in Synaptic to show a lot of info. Just highlighting a package will give you info on the depends for instance.

I would be shocked if there are no some packages listed there that you have no need of at all. Maybe even a majority of them. I would be more shocked if just using the autoremove command did not do some very serious damage to your system.

Yes you can fix it after that. It is a lot easier to not break it in the first place.

Craigevil has given good solid and sound advice, if I were you I would heed it. Snowpine and Tobi have also given good advice. Widget is just full of good advice.

Now to mine and I'll give you an example to clarify it. If you have modified the system in any way your package lists will be different to the "official" package lists. If you have removed any packages at all you may find you have caused the removal of a dependency of a smetapackage. Metapackages are used to pull in a bunch of other packages but have no other use. If you have inadvertantly removed a metapackage dependency you will now see other packages listed as dependencies of that metapackage in the autoremove list.

So as an example say you have removed openoffice/libreoffice you will have caused a meta package to try and install other software like gnomeoffice or something similar. If you do not allow that to install apt will place many parts of Gnome (I can't give an example in KDE but it will do the same) in the autoremove list. If you allow the autoremove you will break your desktop environment and find it near impossible to do simple things like log in, open applications or even (I did this once) shut down.

As already pointed out, autoremove is indicating you now have a dependency problem. My gut feeling is you have accidentally removed a dependencies of a metapackage so the remaining dependencies are listing as autoremoveable.

Actually, I have upgraded a full system (Squeeze with kde) to Wheezy. The upgrade process itself crashed and I had to revive it by issuing and apt-get -f install command. That, complained that it couldn't work because there was a dependency problem. I used dkpg -i to resolve the latter and then apt-get -f install. However, apt-get -f install, continued till the very end of the installation probably assuming it was not a dist-upgrade what I needed. After that, I reapplied an apt-get dist-upgrade to correct the remaining problems and did some package auditing to verify that I did not have any remaining packages from Squeeze.

As long as the system boots in CLI, it should not be a problem, although there is still the chance of using a chroot from within another working installation. That should enable one to repair the system and it would be an interesting experiment to try.

I think, the safest action to take is to backup the entire installation, attempt a removal of the packages from outside kde (with kdm stopped) and reinstall the deleted packages. That should eliminate the need for the missing meta package.

Yes or fix it with it all running anyway. I don't see why you would deliberately complicate the procedure if it will actually boot to KDE and function normally anyway.

@ Reply
 

I did that on Debian:

I do agree with what people have said in the above posts which simply means it is better to be safe then sorry :-) but still I am unable to find the answers of my queries:

1. How apt-get autoremove calculates which packages to be removed.
2. If this option is so disastrous then why it is there.
3. When I did small testing with my Debian system it did not remove any package which was in use when I ran apt-get autoremove.

I mean if it is so dangerous then why does it exist there on the first place. I did try to find more information on this option on Debian's site but was unable to find much.

If we say that autoremove option sometimes remove the stuff which is required by the system then there is a problem with the code. It is like running "clear" command sometimes not only clears the screen but make the screen go black till you reboot :-)

I took a note of the list of packages marked for auto-removal and saved them in a text file. Then I issued the command:
I did the above to set all the listed packages as set to manually installed instead of automatically installed. This led the system to keep the packages while at the same time I can use the autoremove feature for other purposes.

The commands together withe the CLI output are listed below:

1. It simply seeks in its database for packages that are marked as automatically installed but are not dependencies for another package.
2. auto-remove is not dangerous in every case. It can become dangerous when it is used together with meta-packages. It is totally possible to install a Debian system without using any meta-package. It also is totally possible to build your own distro using the APT package management system without any meta-packages. It is just that it is convenient to use meta-packages. The same way you could ask why rm has the -rf option, although doing rm -rf /usr (WARNING, don't do that if you don't want to destroy your system) will in any case render your system unusable.
Since you are only be able to use apt-get auto-remove (or the rm thing) as root, it is up to your responsibility to actually think about what you are doing and read the output on the screen before confirming it.
3. Can not say much about that, I have seen many threads in different forums where auto-remove showed the behavior edbarx described, and back in the days I used Debian I also sometimes had problems with that, especially when using Sid (or Sid/Experimental mixes). If you use package management systems with automatic dependency resolution you should be prepared that sometimes odd things may happen. Again, this is why you always should read what is displayed on the screen before confirming anything (not saying that you don't do that).

Debian's package management system differentiates between:
a) packages that were install explicitly by the user
b) packages that were automatically pulled in by system to satisfy dependences of packages that were installed explicitly.

Furthermore, there are empty packages which do not provide other functionality than providing a list of required packages. These are called meta-packages. If a meta-package is removed, than some/all of its dependencies may be marked as unneeded as they were not explicitly installed by the user. Meta-packages are useful in cases where the user needs a simple command to install a complex suit of software (say kde or gnome) with just the explicit installation of one package, the meta-package.

Personally I only come across this problem when I do a dist-upgrade. In day to day use autoremove just tends to suggest a few packages that, generally, I know can go but when it comes to just after a dist-upgrade, or a new install, I tend to leave autoremove until things settle down.
Might this be caused in part by dependency changes when upgrading, or am I complicating matters and it's just meta-packages?

If you are using the command on a stable system such as Debian stable (Squeeze) there is little chance of a problem. Most problems there will be the result of user actions that change the "state" of the package.

If you are using a non stable OS such as Debian testing or Sid the chances of error are higher. The chances of user actions that change the state of the packages is also, I believe, higher.

That belief is based on my oppinion that users of this type of OS are more adventurous in their use of and play with the installation. I do know for a fact that this is true in at least one case, mine. Could be that I am simply crazy and other users are not.

It is a prefectly good command and very handy. As all tools are designed to be useful in stable OS's the fact that you need to be careful with them in other installs just makes sense.

Update Manager (or Update Mangler as I like to call it) is a good example of this. In a stable environment it is very handy for folks to use to keep their OS up to date.

Every cycle of Ubuntu testing, however, they get a lot of folks complaining that it broke their system. It does break their system.

It is designed to work with repos that are stable. Ubuntu-testing repos can get packages in them that do not have the depends in there yet. It is a newer version, it needs upgraded. The fact that the depends for the older version will not work is not part of the design of UM. It will tell you that it has a "partial upgrade" available. If you choose to use it that is not the fault of the tool.

Autoclean is a similar tool. Use it in Squeeze with a fair amount of confidence if you have not been making a lot of "strange" installs, particularly from the testing or unstable repos.

Use in testing or Sid with a lot of caution. This advice is similar to the advice to use testing or Sid as an OS should be used with caution.

Starting in the Debian experimental repo and migrating progressively through Sid and the testing repos filters the packages that finally arrive in the stable repo that is designed to be the repo for the OS Debian puts out for normal users to use. Those are the users that autoclean is aimed at. Those are the users and conditions it is designed for.

@ Reply
 

@ All

Thanks for explaining.