On Thursday 10 March 2005 10:30 pm, Karsten M. Self wrote: > Note: the problem in question was noted on a different system, though > IRC discussion in #debian and #debian-devel indicates others are seeing > this issue with various versions of aptitude. Version numbers will > differ slightly, should be whatever's current in Sarge as of two days > ago. > > > In a recent (3 day old) netinst of Sarge, a number of packages were > installed via an interactive (full-screen) aptitude session. > > After completion of this install and exiting the session, several > additional packages were specified for install in command-line mode: > > aptitude install <package list> > > Aptitude proceeded to list approximately 100 packages for removal. The > action was canceled, the removed packages listed to a file, and a > revised install command issued including the file contents: > > aptitude install <package list> $( cat file ) > > ...which proceeded successfully. > > There wasn't time to investigate _why_ the packages were marked for > removal, however _none_ of these packages generated any conflicts when > requested in conjunction with the packages initially requested in the > command-line install.
I have no way of figuring out what happened here without more information. > Problem: aptitude should produce consistent results when used from > command-line and interactively. Well, the reason you see this is that the command-line interaction is different than visual mode. At the command-line, aptitude knows that its job is to perform a certain set of actions and preferably as few others as possible (for instance, "aptitude install X Y Z" should install packages X, Y, and Z). aptitude is able to give corresponding hints to the problem resolver, basically saying "come hell or high water, make sure you preserve the states of these packages" (in the previous example, "don't cancel the installations of X, Y, and Z"). In visual mode, in contrast, the interaction between the user and the program is a lot more open-ended, and it's a lot trickier to figure out exactly what the user wants (in fact, I'm not sure it's even possible in principle). So aptitude gives the problem resolver a vaguer set of instructions, basically "try and find a reasonable solution if you can". > There are several existing issues with aptitude not respecting > packagelists supplied via dpkg and dselect as well. Yes, I believe there are other bugs filed about that (aptitude wanting to remove stuff installed with dpkg). Some of this has been fixed in the experimental branch, but there may be problems remaining. > Workarounds: It's relatively easy to resolve the problem as I did, by > passing the list of removed packages on the "install" command. However > this requires the user be aware of the problem up front. Recovery from > large-scale package removal may be difficult or time-consuming, > particularly on dialup or standalone systems in which package cache has > expired. Yes, never ever ever install packages without first checking that the program is doing something sensible. Even the most perfect problem resolution algorithm is guaranteed to do things you don't want sometimes. [0] I have been looking into ways of preventing the resolver from going nuts and removing half the system, but it can be bad enough if just one package that's important to you is removed... Daniel [0] The reason for this is that the ideal solution is not just a function of the sets of available packages/version and their dependency relationship; some of the information needed to compute it is in the user's head, in a manner of speaking. -- /------------------- Daniel Burrows <[EMAIL PROTECTED]> ------------------\ | "That we should wish to cast him down and have no one in his place | | is not a thought that occurs to his mind. That we should wish to | | destroy the Ring itself has not yet entered into his darkest dream." | | -- Gandalf Grayhame | \--------------------- A duck! -- http://www.python.org --------------------/
pgpsLVKiGYWN7.pgp
Description: PGP signature
