> From: Jason Gunthorpe <[EMAIL PROTECTED]>
> This is not a bug. Call it a feature if you like, but you haven't convinced me this is reasonable behavior. Dselect should not permit the user to select a state that the backend will not implement. > If you use the 'confirm and override' feature of dselect the results > will not be exactly as you have set because APT will refuse to > perform an operation that breaks your system. The exact point of "override" seems to me to tell the program to use the current package selections regardless of whether the program thinks they will break my system. I know better than the program in this case, that the current selections will not break the system. Hundreds of times in the past I have concluded a dselect session with "D)irectly-suggested" and "Q)uit & override", and the result has been a system that conforms to my selections. It may be true that all those many times, I was only overriding `recommendations' rather than dependencies, and that APT will allow non-recommended states. In this case, however, the dselect interface leads me to believe that I can override dependency-conflicted states in exactly the same way I can override non-recommended states. Dselect should not permit the user to select a state that the backend will not implement. > Basically you selected an impossible situation and told dselect to > ignore the problem and then expected APT to carry out you impossible > request, which it obviosly doesn't do. `impossible' is not true. using dpkg, i put my system into the state you call `impossible'. (furthermore, this 'impossible' state doesn't even break my system.) it's certainly `possible' for dselect+apt to have put the system in the state I requested. I think you mean `dependency-conflicted'.
