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.