Sorry for the delayed response; I was responding in gaps mid-shift on Monday, and then spent Tuesday actually in the office instead of working remotely. On 2020-04-27 at 15:05, Dale Harris wrote: > On Mon, Apr 27, 2020 at 2:29 PM The Wanderer <wanderer@fastmail.fm> wrote: > >> On initial examination, I see no meaningful issues in that output. >> >> Just to check: is the output of that 'apt-cache policy' command any >> different if you replace 'libwine' with 'libwine:i386'? >> >> If so, please pass along the output from the latter version of the >> command. (My bad; I forgot to specify it in the original case. > > Here's that output: > > # apt-cache policy libwine:i386 I'm sorry, I didn't specify clearly enough. By "that 'apt-cache policy' command", I meant the long and complicated one that already referred to libwine. It should have referred to libwine:i386 instead. In other words, at full length: apt-cache policy $(apt-cache show libwine:i386 | grep Depends | sed 's/[:,] /\n/g' | sed 's/\([^ ]*\) .*$/\1/g' | grep -v Depends | sort -u) It'll probably be easier to diff (or otherwise compare) that against the output of the original long-and-complicated command yourself, and just let me know about the differences, but if you want to provide the full output I can work with that too. (It's occurred to me that there's probably a way to simplify this command, using 'apt-cache depends' or similar, but since we already have this version and it works I'm not too concerned about optimizing it at this point.) >> If not, I'll have to think about the next step. I know what I'd do if I >> had the problem, or had shell access to the box with the problem, but >> trying to turn it into steps someone else can follow remotely (without >> realtime supervision) is a bit trickier. > > Yeah, I understand that, aways easier to do something yourself. > Unfortunately, I can't give you shell access. Entirely understandable. Random stabs in the direction of developing a usable set of steps to follow: since you suspect the system may have a problem with i386 packages to begin with, it might be useful to know whether you actually have any already installed. The first way of finding that out which came to my mind is: dpkg -l '*' | grep ':i386' You can pipe that to wc if you want to get a count, or to less if you want to view the results (since, if there are any, there are likely to be quite a few of them; by coincidence, on my system there are exactly 386). The basic procedure would be an iteration over adding the "will not be installed" packages (or, in the case of a remove-the-wrong-things explosion, the important packages that would otherwise be removed) explicitly to the command line, and repeating with the ones from the next failure, until it shows you the actual conflict. After that, it should be possible to upgrade, downgrade, or remove the right packages - usually, just one, or one small set of related ones - to resolve the problem. That's not detailed step-by-step, however, and it probably looks more daunting as you start in on it than it really is. If you want to do the back-and-forth with giving me output, me suggesting a modified install command, you running it, repeat as needed, I can work with that. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature