wine1.4:i386 not installable on raring amd64

A better option for winetricks may be to mark it multiarch: allowed and depend on winetricks: any, that way it can remain i386/amd64 only (because most of the commands it runs only work on those platforms and we don't yet have an arm wine package)

The attached patch fixes the issue for xdg-utils, which I can't upload because it's in main.

And here's a patch for ttf-wqy-microhei

Here's fonts-unfonts-core

Here's fonts-liberation

This is in fact a bug in apt as well. A fresh install of 64-bit raring will try to pull in gnome-exe-thumbnailer:i386, which in turn will ask for icoutils:i386, which will then conflict:
 libunity-webapps0 : Depends: unity-webapps-service but it is not going to be installed

Rather than give up and declare it hopeless here, apt should instead just not try to install the merely recommended package gnome-exe-thumbnailer:i386.

As a workaround to the apt bug I can properly mark gnome-exe-thumbnailer as Multi-Arch: foreign, of course, since it's just a shell script that calls other programs which can be in the native arch.

Once I fix gnome-exe-thumbnailer, but not winetricks, apt has a similar problem: it gets to the winetricks recommends, determines it wants winetricks:i386, winetricks:i386 says it wants cabextract:i386, this then conflicts with cabextract:amd64. Apt then suggests removing cabextract but not actually installing winetricks due to another conflict, so the suggested removal of cabextract is unnecessary.

I'm beginning to think I need to make some automated tests for an elaborate series of multi-arch edge cases.

This bug was fixed in the package gnome-exe-thumbnailer - 0.9-0ubuntu2

---------------
gnome-exe-thumbnailer (0.9-0ubuntu2) raring; urgency=low

  * Mark package Multi-Arch: foreign (LP: #1123710)
 -- Scott Ritchie <email address hidden> Fri, 15 Feb 2013 17:10:27 -0800

winetricks is actually arch: all now, so no need to change wine1.4 (we now inherit winetricks from Debian)

> I'm beginning to think I need to make some automated
> tests for an elaborate series of multi-arch edge cases.

Hi Scott

Seems that wine is bringing a lot of these m-a issues to your desk :-)

Hopefully this:

> winetricks is actually arch: all now

will be sufficient to avoid immediately having to m-a: foreign the winetricks dependencies. In Debian unstable, cabextract (d) and xdg-utils (r) are the only *declared* dependencies not already marked. These should still be done in due course and I see you are tracking this as bug #905055; great.

I suspect there may be still some cases where it would help for winetricks to also be m-a: foreign (e.g. the user in debian bug #696591 has installed a foreign-arch wine package).

This bug was fixed in the package winetricks - 0.0+20121030+svn918-2

---------------
winetricks (0.0+20121030+svn918-2) unstable; urgency=low

  * debian/control:
    - (Multi-Arch): foreign (new field; Closes: #696591). This
      should satisfy dependencies of a package of a different
      architecture, like win64 or win32.
  * debian/copyright
    - Update year.

 -- Jari Aalto <email address hidden> Sat, 16 Feb 2013 19:23:15 +0200

Thanks Daniel :)

I saw that bug too and typed out a lengthy reply asking much the same thing, but it turns out I never hit send for some strange reason. Regardless, fixed now and synced to Ubuntu.

> This is in fact a bug in apt as well. A fresh install of 64-bit raring will
> try to pull in gnome-exe-thumbnailer:i386, which in turn will ask for
> icoutils:i386, which will then conflict:
> libunity-webapps0 : Depends: unity-webapps-service but it is not going to be installed
>
> Rather than give up and declare it hopeless here, apt should instead just not
> try to install the merely recommended package gnome-exe-thumbnailer:i386.

I'm not so sure this is sensible, as relaxing the behaviour of APT::Install-Recommends will lead to unpredictable results, especially in the presence of other transient packaging or non-availability errors. The expectation when installing a package is that any recommends are also installed. If a recommended package is not available at the time and simply ignored, it will not be handled subsequently by upgrades to the base package. This is important behaviour to preserve the users ability to manually override particular recommends.

To quote debian-policy:

> Recommends
> This declares a strong, but not absolute, dependency.
>
> The Recommends field should list packages that would be found
> together with this one in all but unusual installations.

If a package recommends another that is either unavailable or uninstallable, that is not merely an unusual situation, it is *broken*. In my understanding, the treatment of recommends as dependencies *while installing a package* should not be changed unless manually overridden (by, say, ‘apt-get install foo bar-’). If a package recommends another, it is declaring a relationship that is expected to hold by default and care must be taken to ensure that recommended packages are co-installable (i.e. m-a foreign down as far as required).

I would consider this issue purely packaging and mark as invalid for apt, though perhaps some apt developers have a comment.

Regards

I agree with the sentiment about apt, however I thought it was the current case that if a recommended (same-arch) package isn't available in the archive, it does get simply ignored.

On 19 February 2013 03:54, Scott Ritchie <email address hidden> wrote:
> I agree with the sentiment about apt, however I thought it was the
> current case that if a recommended (same-arch) package isn't available
> in the archive, it does get simply ignored.

Quite right, for ‘install’ and ‘dist-upgrade’ at least. Curiously
this is inconsistent when ‘upgrade’, which will not upgrade a package
with missing recommends. Perhaps they should be handled consistently
one way or the other, prefering the safety of not installing the base
package.

Relaxing the behaviour in the multiarch case is probably not so
useful, as then foo:foreign and foo:native will unpredictably have
different capabilities due to recommends.

Attached is a test case for apt attempting to capture the situation in
the report. On Debian sid (apt 0.9.7.6) it does not recreate the not
installable result yet, so needs some further tweaking.

Output from a failed install with ‘-oDebug::pkgProblemResolver=1’ is appreciated. The Debian wine packaging is substantially different.

That "apt-get upgrade" behaves this way as it wants to be VERY careful and breaking a recommendation is not a safe operation. Consider situations in which A=1 and B=1 are installed and A recommends B >= 1. Now A=2 enters the archive with B >=2 as recommendation. Upgrading A now would mean we break the recommendation which might very well be an important feature of A which from a user point of view just disappeared after an operation which is considered to be safe and might be even done fully automated! In the case of a new recommends it might be safe, but it might as well be that a package was split or an old feature now needs an addition recommends to work properly …

For "install" and "dist-upgrade" a more visible indication of which recommendations are going down the drain if you apply this solution would indeed be good though (I think aptitude does it) Currently you only get a report about recommends which are not satisfied by this install, not which are going to be broken (on already installed packages). A mode to get the same behavior into "dist-upgrade" and co would be interesting, too – but not as default I guess – as their behavior is defined differently.
(If I recall correctly the implementation in "upgrade" is kinda hacky, so working on it wouldn't hurt either way)

Status changed to 'Confirmed' because the bug affects multiple users.

I cant install Wine on x64 raring. It says that dependencies are not satisfied...

ttf-* are names of transitional binary packages, the corresponding source packages were renamed a few cycles ago.

I still cant install Wine on x64 raring

All four patches sponsored. xdg-utils is set Multi-Arch: foreign in Debian unstable already. Please make sure that the multiarch patches for the fonts make its way into Debian.

This bug was fixed in the package fonts-liberation - 1.07.2-6ubuntu1

---------------
fonts-liberation (1.07.2-6ubuntu1) raring; urgency=low

  * Mark package Multi-Arch: foreign (LP: #1123710)
 -- Scott Ritchie <email address hidden> Wed, 20 Mar 2013 19:32:44 +0100

This bug was fixed in the package fonts-unfonts-core - 1.0.3.is.1.0.2-080608-5ubuntu3

---------------
fonts-unfonts-core (1.0.3.is.1.0.2-080608-5ubuntu3) raring; urgency=low

  * Mark package Multi-Arch: foreign (LP: #1123710)
 -- Scott Ritchie <email address hidden> Wed, 20 Mar 2013 19:30:12 +0100

This bug was fixed in the package ttf-wqy-microhei - 0.2.0-beta-1.1ubuntu3

---------------
ttf-wqy-microhei (0.2.0-beta-1.1ubuntu3) raring; urgency=low

  * Mark as Multi-Arch: foreign (LP: #1123710)
 -- Scott Ritchie <email address hidden> Wed, 20 Mar 2013 19:25:13 +0100

This bug was fixed in the package xdg-utils - 1.1.0~rc1-2ubuntu7

---------------
xdg-utils (1.1.0~rc1-2ubuntu7) raring; urgency=low

  * Mark as Multi-Arch: foreign (Closes: #688681, LP: #1123710)
 -- Scott Ritchie <email address hidden> Wed, 20 Mar 2013 19:37:26 +0100

On 14 May 2013 16:12, Daniel <email address hidden> wrote:
> ** Attachment added: "As of 2013-05-14, this is what I still get when trying to install wine with current package database (apt-get update)"
> https://bugs.launchpad.net/ubuntu/+source/winetricks/+bug/1123710/+attachment/3676137/+files/unmet-dependencies.png
>

That image does not indicate which dependencies are not met.

Also, you must say which distribution you are using (raring, etc.).

@Daniel Hartig: you are right. Now my system is up again to get more info:

lsb_release -a:
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description: Ubuntu 13.04
  Release: 13.04
  Codename: raring

uname -a:
  Linux 3.8.0-19-generic #30-Ubuntu SMP Wed May 1 16:35:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

apt-get install wine (version 1.4.1-0ubuntu5)
  The following packages have unmet dependencies:
   wine : Depends: wine1.4 but it is not going to be installed
apt-get install wine1.4
  The following packages have unmet dependencies:
   wine1.4 : Depends: wine1.4-i386 (= 1.4.1-0ubuntu5) but it is not installable

Exact problem:

* wine depends on wine1.4
 * (not relevant:) wine1.4 (i386 version) only depends on wine1.4-i386
 * wine1.4 (amd64 version) depends on both wine1.4-amd64 and wine1.4-i386
  * wine1.4-amd64 is available
  * wine1.4-i386 is only available for i386, but is also needed by wine1.4 (amd64 version)

On 15 May 2013 20:02, Daniel <email address hidden> wrote:
> The following packages have unmet dependencies:
> wine1.4 : Depends: wine1.4-i386 (= 1.4.1-0ubuntu5) but it is not installable
>

So you probably want to enable i386 repositories to use wine:

$ sudo dpkg --add-architecture i386
$ sudo apt-get update
$ sudo apt-get install wine

and maybe with --no-install-recommends on the last one.

Note that this is not the same issue described in this bug report.

> sudo dpkg --add-architecture i386
Is this the way that each Ubuntu user should go? I never saw this command before and I think it should not be necessary for packages from the universe repository.

> Note that this is not the same issue described in this bug report.
probably. But I think the 'solution' of this bug is the origin of my issue. Your efforts to solve the bug are responsible that wine cannot be installed anymore on amd64

On 15 May 2013 22:22, Daniel <email address hidden> wrote:
>> sudo dpkg --add-architecture i386
> Is this the way that each Ubuntu user should go? I never saw this
> command before and I think it should not be necessary for
> packages from the universe repository.
>

Usually it is not required. The i386 is supposed to be enabled by
default on all (desktop) Ubuntu amd64 systems. There are a few
reports that certain install methods are not doing that, but otherwise
it is fine for most.

>> Note that this is not the same issue described in this bug report.
> probably. But I think the 'solution' of this bug is the origin of my issue. Your efforts to solve the bug are responsible that wine cannot be installed anymore on amd64
>

This bug tracks enabling multiarch for packages in the
depends/recommends tree of wine. That is not related to the issue you
are experiencing.

If you do not have i386 repositories enabled, that is a
misconfiguration of your system. Wine is not going to be installable
on pure amd64, that would be a return to the chaos before multiarch.

If you continue to have issues, I recommend you seek help on a support
forum. See <http://www.ubuntu.com/support/>. If that process
identifies an actual bug, then please file a new report.