Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
        installing smokeping
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
        apache2 was made to autostart after installing smokeping, it was not
stopped from autostarting after purging smokeping and running autoremove
   * What outcome did you expect instead?
        apache2 to not autostart after having purged smokeping and having run
autoremove

*** End of the template - remove these lines ***

I can't see anything wrong in apache2 dependencies, nor in smokeping ones.

When installing smokeping, then uninstalling it, some recommended
packages are left, such as javascript-common in my case.

Moreover, if I uninstall javascript-common, aptitude propose me to
uninstall apache2 next time I run it.
apt-get autoremove does not propose that.

I guess this is an issue with apt. Reassigning.

Hi Jason & Jean-Michel,

Jason, your bugreport got reassigned to apt today,
Jean-Michel, you reassigned it to us.

My question for both of you is how I can reproduce this problem as if I build a
minbase chroot of testing, install smokeping and after that call
$ apt-get autoremove --purge smokeping
it happily removes apache2 with smokeping (and javascript-common, too).

This keeps many packages installed (204 newly installed vs 78 removed), but
these are all recommends/suggests of other packages still installed.

Letting the autoremover run free with
-o APT::AutoRemove::RecommendsImportant=false -o APT::AutoRemove::SuggestsImportant=false
will cause all packages which were installed to be removed again, but as said,
it breaks recommends/suggests of packages (I guess there are some
recommends/suggests cycles here as well).

So, how am I able to reproduce this and/or are you sure nothing else on your
system recommends/suggests apache2 keeping it installed.

Also, does print
$ apt-mark showauto apache2
'apache2' or is the output empty?


The code for the autoremover is shared in libapt, so I would expect apt and
aptitude to have the same result, just that aptitude runs the autoremover by
default for all actions while it is an extra command in apt-get.


Best regards

David Kalnischkies

Hi

I'm not the original submitter. I think most user don't care much about
recommends, suggests and so on... If they install a package and some
dependencies are pulled, they very probably want autoremove to remove
them all when the original package is removed. That doesn't seem to
work. Because the report was initially submitted against pseudo package
bugs.debian.org, my guess is that's it...
The whole system is rather difficult to explain.



I mostly wanted the report out of apache2. Sorry. ^^


Regarding your question, I have here a configuration here where aptitude
suggests apache2/apache2-bin/apache2-data/apache2-utils removal, and
"apt-get autoremove" does not. Should we clone that report?

But there are circular dependencies, like:
- apache2 depends on apache2-bin
  - apache2-bin suggests apache2-doc (UNSATISFIED)
    - apache2-doc recommends apache2

Also, here, I have a very ugly mix of jessie, testing and sid packages,
plus a few I built myself and installed with a dpkg -i. :/

Would you like a full list of packages and versions?



David Kalnischkies wrote:

Well, that depends. It probably is that way if you install something,
doesn't like it and remove it again, but in general you don't want apt
to remove recommends/suggests as this means that a package looses
features. Like, say your texteditor recommends a package it needs to
print stuff for you. You can use your texteditor without ever printing
stuff, so a dependency would be wrong, but people would quickly start
complaining if there texteditor can't print stuff anymore as apt decided
that recommends do not need to be installed anymore (especially as
recommends are installed by default, so ignoring this relation in
autoremove would mean removing the just installed recommends again…).

Well, one of my DebCamp projects is it to triage some apt bugs, so you
were "lucky" that someone responded to your reassign. :P
of a system were it happens, that should be enough to reproduce it.

Usual disclaimer: dpkg/status contains information about all packages
you have installed on your system and in which version. If you don't
want to expose this information in public, feel free to sent it
privately to me.


Best regards

David Kalnischkies