wine1.4:i386 not installable on raring amd64

Bug #1123710 reported by Scott Ritchie on 2013-02-13
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
fonts-droid (Ubuntu)
Undecided
Scott Ritchie
fonts-horai-umefont (Debian)
Fix Released
Unknown
fonts-horai-umefont (Ubuntu)
Undecided
Scott Ritchie
fonts-liberation (Debian)
Fix Released
Unknown
fonts-liberation (Ubuntu)
Undecided
Scott Ritchie
fonts-unfonts-core (Debian)
Fix Released
Unknown
fonts-unfonts-core (Ubuntu)
Undecided
Scott Ritchie
gnome-exe-thumbnailer (Ubuntu)
Medium
Scott Ritchie
ttf-wqy-microhei (Debian)
Fix Released
Unknown
ttf-wqy-microhei (Ubuntu)
Undecided
Scott Ritchie
winetricks (Debian)
Fix Released
Unknown
winetricks (Ubuntu)
Low
Scott Ritchie
xdg-utils (Ubuntu)
Undecided
Scott Ritchie

Bug Description

If a user wants 32-bit only wine, a reasonable way to get it would be to install wine1.4:i386. However, this is not possible on amd64. Currently apt spews this complaint:

 wine1.4:i386 : Depends: wine1.4-i386:i386 (= 1.4.1-0ubuntu4)
                Recommends: gnome-exe-thumbnailer:i386 but it is not installable or
                            kde-runtime:i386 but it is not going to be installed
                Recommends: ttf-droid:i386 but it is not installable
                Recommends: ttf-liberation:i386 but it is not installable
                Recommends: ttf-umefont:i386 but it is not installable
                Recommends: ttf-unfonts-core:i386 but it is not installable
                Recommends: ttf-wqy-microhei:i386 but it is not installable
                Recommends: winetricks:i386 but it is not going to be installed
                Recommends: xdg-utils:i386 but it is not installable

gnome-exe-thumbnailer, xdg-utils, and the fonts are arch: all and should be marked multiarch:foreign to indicate that it is ok to install them for the nonnative wine1.4 (they are cross-arch shell scripts). winetricks is currently arch i386 and amd64 and should probably be marked arch: all (especially for upcoming arm wine).

apt will then freak out about conflicts and give up. apt-get --no-install-recommends wine1.4:i386, however, will actually complete. I'm not sure this is correct behavior for apt, as in principle it should be able to figure out that it can succeed with the command by omitting recommended packages.

Scott Ritchie (scottritchie) wrote :

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)

Changed in winetricks (Ubuntu):
assignee: nobody → Scott Ritchie (scottritchie)
importance: Undecided → Low
status: New → Triaged
description: updated
Scott Ritchie (scottritchie) wrote :

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

Changed in xdg-utils (Ubuntu):
status: New → Fix Committed
assignee: nobody → Scott Ritchie (scottritchie)
Changed in wine1.4 (Ubuntu):
status: New → Triaged
importance: Undecided → Low
assignee: nobody → Scott Ritchie (scottritchie)
Scott Ritchie (scottritchie) wrote :

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

Changed in ttf-wqy-microhei (Ubuntu):
status: New → Fix Committed
assignee: nobody → Scott Ritchie (scottritchie)
Changed in ttf-unfonts-core (Ubuntu):
assignee: nobody → Scott Ritchie (scottritchie)
Changed in ttf-umefont (Ubuntu):
assignee: nobody → Scott Ritchie (scottritchie)
Changed in ttf-liberation (Ubuntu):
assignee: nobody → Scott Ritchie (scottritchie)
Changed in ttf-droid (Ubuntu):
assignee: nobody → Scott Ritchie (scottritchie)
Changed in ttf-unfonts-core (Ubuntu):
status: New → Fix Committed
Scott Ritchie (scottritchie) wrote :

Here's fonts-unfonts-core

Changed in ttf-umefont (Ubuntu):
status: New → Fix Committed
Changed in ttf-unfonts-core (Ubuntu):
status: Fix Committed → In Progress
Changed in ttf-wqy-microhei (Ubuntu):
status: Fix Committed → In Progress
Changed in xdg-utils (Ubuntu):
status: Fix Committed → In Progress
Scott Ritchie (scottritchie) wrote :

Here's fonts-liberation

Changed in ttf-liberation (Ubuntu):
status: New → In Progress
Scott Ritchie (scottritchie) wrote :

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.

Scott Ritchie (scottritchie) wrote :

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.

Changed in gnome-exe-thumbnailer (Ubuntu):
assignee: nobody → Scott Ritchie (scottritchie)
importance: Undecided → Medium
status: New → Triaged
Changed in ttf-droid (Ubuntu):
status: New → Fix Committed
Scott Ritchie (scottritchie) wrote :

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.

Changed in gnome-exe-thumbnailer (Ubuntu):
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-exe-thumbnailer (Ubuntu):
status: Fix Committed → Fix Released
Scott Ritchie (scottritchie) wrote :

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

Changed in wine1.4 (Ubuntu):
status: Triaged → Invalid
Daniel Hartwig (wigs) wrote :

> 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).

Changed in debian:
status: Unknown → New
Changed in debian:
status: New → Fix Released
Jeremy Bicha (jbicha) wrote :

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

Changed in winetricks (Ubuntu):
status: Triaged → Fix Released
Scott Ritchie (scottritchie) wrote :

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.

Daniel Hartwig (wigs) wrote :

> 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

Scott Ritchie (scottritchie) 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.

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.

Daniel Hartwig (wigs) wrote :

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

David Kalnischkies (donkult) wrote :

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)

Launchpad Janitor (janitor) wrote :

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

Changed in apt (Ubuntu):
status: New → Confirmed

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

affects: debian → winetricks (Debian)
no longer affects: wine1.4 (Ubuntu)
affects: ttf-unfonts-core (Ubuntu) → fonts-unfonts-core (Ubuntu)
Dmitry Shachnev (mitya57) wrote :

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

affects: ttf-droid (Ubuntu) → fonts-droid (Ubuntu)
affects: ttf-liberation (Ubuntu) → fonts-liberation (Ubuntu)
affects: ttf-umefont (Ubuntu) → fonts-horai-umefont (Ubuntu)
Changed in fonts-horai-umefont (Ubuntu):
status: Fix Committed → Fix Released

I still cant install Wine on x64 raring

Changed in fonts-droid (Ubuntu):
status: Fix Committed → Fix Released
tags: added: patch
Benjamin Drung (bdrung) on 2013-03-20
Changed in ttf-wqy-microhei (Ubuntu):
status: In Progress → Fix Committed
Changed in fonts-unfonts-core (Ubuntu):
status: In Progress → Fix Committed
Benjamin Drung (bdrung) on 2013-03-20
Changed in fonts-liberation (Ubuntu):
status: In Progress → Fix Committed
Changed in xdg-utils (Ubuntu):
status: In Progress → Fix Committed
Benjamin Drung (bdrung) wrote :

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.

Launchpad Janitor (janitor) wrote :

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

Changed in fonts-liberation (Ubuntu):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in fonts-unfonts-core (Ubuntu):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in ttf-wqy-microhei (Ubuntu):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in xdg-utils (Ubuntu):
status: Fix Committed → Fix Released
no longer affects: apt (Debian)
no longer affects: xdg-utils
Changed in fonts-liberation (Debian):
status: Unknown → New
Changed in fonts-unfonts-core (Debian):
status: Unknown → New
Changed in ttf-wqy-microhei (Debian):
status: Unknown → New
Daniel Hartwig (wigs) wrote :

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 (hackie) wrote :

@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)

Daniel Hartwig (wigs) wrote :

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.

Daniel (hackie) 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.

> 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

Daniel Hartwig (wigs) wrote :

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.

Changed in fonts-horai-umefont (Debian):
status: Unknown → New
Changed in fonts-horai-umefont (Debian):
status: New → Fix Released
Changed in fonts-liberation (Debian):
status: New → Fix Released
Changed in ttf-wqy-microhei (Debian):
status: New → Fix Committed
Changed in ttf-wqy-microhei (Debian):
status: Fix Committed → Fix Released
no longer affects: apt (Ubuntu)
Changed in fonts-unfonts-core (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.