On Wednesday 22 June 2005 09:31 pm, Elliott Mitchell wrote: > I suppose it could be. I was guessing state saving was fine, as most were > fine, just those four. > > > If you'd mentioned the bit about quitting and restarting the program > > originally, you could have avoided a long and tedious lecture on problem > > resolution ;-). > > "I'm having to take care of this over a number of sessions". See the > above for why I didn't place emphasis on this point.
In case you're curious, I can explain what the problem is; that should explain why it only hits some packages. (I'd appreciate it if you could test the patch, btw, since I'm not sure this applies to your situation -- I can build patched packages for you if you want) A simple case is when you have three packages: A, B, and C, and the following dependencies: A Depends (B | C) Say that nothing is installed, but you have A and B selected for installation. aptitude will properly save these selections when you quit. However, when you restart the program, the initial state is for nothing to be done: i.e., A, B, and C will remain uninstalled. When aptitude goes to restore your state, one of two things will happen: (a) first aptitude marks C for installation. Everything is OK. Then it marks A for installation, and everything remains OK. That's reasonable, but see below... (b) first aptitude marks A for installation. But A has a broken dependency -- remember, C is not yet marked for installation! Since aptitude was (erroneously) requesting immediate dependency resolution, apt's dependency resolver kicks in and marks B for installation automatically. Then aptitude marks C for installation. Annoyingly, this general class of bug has turned up before, most notably when upgrading stuff (you have to do it in two passes to avoid odering problems like this; however, this doesn't work in general because of Conflicts, versioned deps, etc). I can't think what I was thinking when I enabled the resolver in this place, because it's just not right to be using it, even aside from these problems -- we want to restore the user's settings, not helpfully "fix" them. The reason might have been to handle the corner case where the package lists change in between sessions, but I think this misbehavior is much worse than having some packages become broken on startup. Daniel -- /------------------- Daniel Burrows <[EMAIL PROTECTED]> ------------------\ | Imagine if every Thursday your shoes exploded if you | | tied them the usual way. This happens to us all the | | time with computers, and nobody thinks of complaining. | \- Does your computer have Super Cow Powers? ------- http://www.debian.org -/
pgp101gxL6Rp8.pgp
Description: PGP signature
