Re: [lmi] Problem upgrading 'wine'

[Vadim Zeitlin]

On Wed, 23 Jan 2019 16:30:23 +0000 Greg Chicares <address@hidden> wrote:

GC> Vadim--I use 'wine' only in a chroot, debian_version being:
GC> 
GC>   /home/greg[0]$cat /etc/debian_version 
GC>   9.6
GC>   /home/greg[0]$cat /srv/chroot/lmi-buster/etc/debian_version
GC>   buster/sid

 Unfortunately I don't have exactly the same chroot to try to reproduce
your problem in exactly the same circumstances: on one hand, I have a 64
bit Sid chroot and OTOH I have a probably very similar Buster chroot, but
it's 32 bits only (precisely because I didn't want to bother with 64 bit
complications for Wine).

GC> for host and chroot. Today I successfully upgraded the host with
GC> the same series of command I always use:
GC>   #apt-get update
GC>   #apt-get upgrade
GC>   #apt-get dist-upgrade
GC>   #apt-get autoremove
GC> but when I then tried to upgrade the chroot in the same way,
GC> on the second step I saw:
GC> 
GC> 
---------8<--------8<--------8<--------8<--------8<--------8<--------8<-------
GC> #apt-get upgrade     
GC> Reading package lists... Done
GC> Building dependency tree       
GC> Reading state information... Done
GC> Calculating upgrade... Done
GC> Some packages could not be installed. This may mean that you have
GC> requested an impossible situation or if you are using the unstable
GC> distribution that some required packages have not yet been created
GC> or been moved out of Incoming.
GC> The following information may help to resolve the situation:
GC> 
GC> The following packages have unmet dependencies:
GC>  wine : Depends: wine64 (>= 4.0~rc6-1) but 3.0.3-2 is to be installed or
GC>                  wine32 (>= 4.0~rc6-1)
GC> E: Broken packages
GC> 
--------->8-------->8-------->8-------->8-------->8-------->8-------->8-------

 So all I can say is that I've just updated my own Buster chroot using "apt
update && apt full-upgrade" (which should be functionally equivalent to the
apt-get commands above) without any problems. And wine did get updated to
4.0~rc6-1, here is "apt-cache policy wine" output before:

wine:
  Installed: 3.0.2-3
  Candidate: 4.0~rc6-1
  Version table:
     4.0~rc6-1 500
        500 http://httpredir.debian.org/debian buster/main i386 Packages
 *** 3.0.2-3 100
        100 /var/lib/dpkg/status

and after:

wine:
  Installed: 4.0~rc6-1
  Candidate: 4.0~rc6-1
  Version table:
 *** 4.0~rc6-1 500
        500 http://httpredir.debian.org/debian buster/main i386 Packages
        100 /var/lib/dpkg/status

But, as indicated by "i386" above, this is a 32 bit chroot, so there is no
wine64 there.

 As for my 64 bit chroot, I had actually already upgraded Wine in it before
without even noticing -- without speaking of having any problems with it.

GC> My currently-installed version
GC>   $wine --version
GC>   wine-3.0.3 (Debian 3.0.3-2)
GC> still works (lmi's msw GUI test still runs successfully), so the
GC> "Broken packages" message would seem to refer to the new version 4,
GC> and I'd be tempted to guess that this message:
GC>   wine : Depends: wine64 (>= 4.0~rc6-1) but 3.0.3-2 is to be installed
GC> means that apt-get thinks that the 'wine' package requires a new
GC> 'wine64', but that the old 'wine64' is required for some other reason.

 Yes, this is absolutely correct. The trouble is that I don't see at all
what could this reason be. What does "apt-cache policy wine64" tell you and
what happens when you explicitly try to install this package, i.e. "apt
install wine64"?

GC> (Is there any real likelihood that debian's 'wine' packaging is really
GC> inconsistent, and has remained so for about a month?)

 It seems unlikely and I don't see any such problem here...

GC> I recall that some time ago we discussed using a 'wine' backport,

 This would only make sense when using stable (i.e. Stretch), but there is
no backports for testing (Buster currently). As you can see at e.g.

https://packages.debian.org/search?keywords=wine64&searchon=names&suite=all&section=all

only Buster and Sid have Wine 4.0 now and Stretch is still at 1.8, while
3.0 is available in Stretch backports.

GC> but I don't seem to be using any backports in this chroot:
GC> 
GC>   $cat /etc/apt/sources.list 
GC>   deb http://deb.debian.org/debian/ buster main
GC>   deb http://deb.debian.org/debian/ buster-updates main
GC>   deb http://security.debian.org/   buster/updates main
GC> 
GC> so I don't know why its debian_version is 'buster/sid'.

 I have to admit I didn't know neither, I just remembered that it was
"normal", but https://unix.stackexchange.com/a/464813/20551 explains it
clearly and convincingly.

GC> Anyway, what should I do now?

 I'm quite certain the problem shouldn't be impossible to fix, but it might
take some time to find the real reason for it, so if you don't have
anything important in this chroot and if your creation of it is automated
(I believe you have scripts, or at least a sequence of commands, for
creating it?), then it might be faster to indeed just create a new one.

 If you do want to fix it, I'd try, in order of difficulty:

1. Run "apt full-upgrade" or "apt-get dist-upgrade" directly, i.e. let apt 
   remove/add packages and not just upgrade them. Perhaps this is all you
   need to make the update succeed.

2. If it still fails with the same error, try updating packages one by one
   explicitly with "apt install" (or "apt-get install", but they're really
   the same). Typically, this will involve doing it several times by
   tracing the package dependencies, but eventually you should find the
   package which is the real root of the problem.

3. I don't actually know any following steps because (2) was always enough
   for me to solve all the problems I've ever had. Please let me know if it
   still isn't for you. BTW, I assume that you haven't actually pinned any
   packages (including wine), but if you do have /etc/apt/preferences (or
   anything in /etc/apt/preferences.d directory, but this seems even less
   likely), please let me know.

 Good luck!
VZ