Bug#2834: desect loses state if it can't find a pre-dependancy
Chris Fearnley writes ("Bug#2834: desect loses state if it can't find a pre-dependancy"):
> When dpkg-1.1.5elf is on the disk (from a clean install) and
> dpkg-1.1.5aout is on the volume where the .deb files live (say from a
> mirror) dpkg fails to install libc4 (if it's on hold like I had it).
> That's fine, but when I went to take libc4 off hold dselect forgot
> about my nfs mounted partition and I had to redo several preliminary
> steps (and it was trial-and-error to determine which steps were
> necessary).
I'm puzzled about this. Did you go back to [A]ccess, or retry
[U]pdate or [I]install ? If you went back to [A]ccess then you should
expect to have to confirm that the things you did last time were still
right.
I'm afraid your bug report is a little low on detail.
> Also, there really needs to be a way to back out of deselect's conflict
> resolution screen (CRS). Once I picked a package that required some
> small package from TeX. Then when I went to unselect it, I ended up in
> another CRS with a few more TeX packages, and this process repeated
> several annoying times before I selected all the TeX stuff (rather than
> unselecting them as I wanted to do) to get back to the main selection
> screen where I could deselect them all in one fell swooop (which
> worked). I think deselect doesn't follow recursive dependancies, but
> when there are some the user ends up in a recursive series of CRS
> screens, urrgh.
dselect does follow recursive dependencies, or tries to. You probably
fiddled with things in a way that meant it had to drag in more stuff.
Without more detail there's not much I can do.
Ian.
Reply to: