Bug#50223: delect removes diald when it shouldn't
> From: Jason Gunthorpe <jgg@ualberta.ca>
> 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'.
Reply to: