Re: Bug#88968: Possibly leaves stuff in apt.conf, dies when it does
On Thu, Mar 08, 2001 at 08:17:49PM -0500, Matt Zimmerman <email@example.com> was heard to say:
> > (b) Assuming the above doesn't happen, you still run into trouble if the
> > user is using an apt frontend other than apt-get. These programs generally
> > parse /etc/apt/apt.conf on startup and use its values while the program is
> > running. If the user upgrades from inside a frontend, then tries to do
> > another dpkg run, the frontend will use the old apt.conf settings to invoke
> > apt-listchanges. (this is, I believe, what happened to me. It certainly
> > explains why restarting the frontend "solved" the problem)
> This is an interesting problem. I'll close the bug against apt-listchanges,
> but it might be worth reporting a bug against aptitude to reload the
> configuration, re-exec itself, or something after performing an upgrade. What
> does it currently do if, for example, apt is upgraded? Is that case handled
> specially? What if, say, the Dir hierarchy in apt.conf is changed?
apt isn't handled specially. There's no barrier to reparsing apt.conf,
but it could cause ugliness if the user has modified options during the
program's run. It hasn't been an issue for me in the past.
(I have considered creating an option to re-exec after aptitude upgrades
itself, but I'm not totally sure it's a good idea)
> This is definitely a problem that current and future frontends need to
> consider. I'm CCing the APT development team to see what they think.
Being lazy, I'd prefer that someone else handled it :P But anyway..
Re-execing or reloading the configuration sounds like maybe the least bad
option, but I don't really like it. I think more thought on my part, or a
better idea from someone else, is indicated..
/-------------------- Daniel Burrows <firstname.lastname@example.org> -------------------\
| He had a terrible memory. He remembered everything. |
\------------- Debian GNU/Linux http://www.debian.org -- Because. ------------/