On Sunday 17 June 2007 20:22:20 Daniel Burrows wrote:
> Ooh, that's a nasty one. To make it more fun, it occurs in the
> previous releases of aptitude as well.
>
> I think I have a pretty good idea what's going on.
>
> (1) You install wesnoth with apt-get. So far so good.
> (2) You remove wesnoth with aptitude, *from the command-line*.
> aptitude writes out that it wants to remove wesnoth and
> that wesnoth is currently installed, but in order to save
> time after the install, it doesn't refresh the package
> states or write out the new installation states.
> (3) You install wesnoth again. Yay.
> (4) You run aptitude. On startup, it checks its state and
> sees that it wants to remove wesnoth, and that the last
> time it saw wesnoth, wesnoth was installed. It checks
> wesnoth, and sees that hey, it's still installed, so
> apparently you never changed it. So it goes ahead and
> removes wesnoth like you wanted.
>
> The problem can be fixed by reading/writing the installation
> states again after step 2, at the cost of making installs take
> longer. Other than that, it's pretty difficult.
I guess that the extra time it takes doesn't matter very much. aptitude
already takes some time to start up, and writes extended state information
after an install run, so I guess the cost would be negligible.
I see that aptitude does read the package states at load time. Can that
information be kept so that there is no need to re read the states after step
2?
>
> What I really want is to be able to say, "only apply my stored state
> if no-one else updated this package since I last saw it". But dpkg
> does not provide any way to find out whether a package has been
> changed since it was last seen. So aptitude guesses by looking at
> whether the package's installation state has changed; as you can
> see here, though, this is a very error-prone way of doing things.
What I'm thinking right now is why would aptitude want to think differently
from what the state db says? If the package is marked to be
installed/removed, then just install/remove it. This kind of smells like when
programs think they know better than the user.
--
Felipe Sateler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
