Control: tags -1 + moreinfo Control: severity -1 minor
Hi all, 2008-06-11 19:10 Jamey Sharp:
Package: aptitude Version: 0.4.11.3-1 Severity: normal After removing a package that installed files in /etc/apt/apt.conf.d, such as apt-listchanges, aptitude still uses the configuration settings from that package. In this case, it tried to invoke apt-listchanges at the beginning of the next dpkg run in the same session, but that program was no longer installed.
I tried to reproduce this (with apt-listchanges and apt-listbugs, from the merged bug report). When purging the file that they install is removed now, rather than disabled. With apt-listchanges, it just emits an error: Performing actions... /bin/sh: 1: /usr/bin/apt-listchanges: not found (Reading database ... 210066 files and directories currently installed.) So the problem looks very very minor, perhaps with apt-listbugs or others is more severe. apt assumes that sessions are not "reused" since it works by single invokations, but aptitude is mostly interactive. I don't think that it's very feasible to re-read the config, because after reading the config from apt in the beggining, aptitude adds configuration on top (temporary for that session only, sometimes), so it would basically need to be "restarted" again internally even if not explicitly, so I don't think that there's much advantage. The number of applications modifying apt's config or the frequency of their installations should not very high, perhaps once every few years in each system even if using these tools, so one of the suggested solutions of re-reading it after every installation of any package seems quite overkill to me, and the time investment needed quite high for little benefit. So at the moment I am leaning towards a +wontfix, leaving it open for further consideration. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
