[pkg-wine-party] Bug#535154: Bug#535154: wine: package broken after /emul -> /usr/lib32 transition

Török Edwin edwintorok at gmail.com
Wed Jul 1 07:28:34 UTC 2009


On 2009-06-30 18:37, Ove Kaaven wrote:
> severity 535154 important
> stop
>
> (For other Wine bugs related to the ia32 transition, see #534238,
> #533315, and #535097.)
>
> Török Edwin skrev:
>   
>> I reported a bug for libc6-i386 that it should have a Breaks: wine, because it
>> broke wine during the transition.
>>     
>
> There might not be much reason for them to, as only Wine versions in
> experimental were affected. Nothing happened to those in lenny and sid
> (they use /usr/lib, not /usr/lib32). Also, even if they did care about
> experimental, there probably aren't any broken Wine package versions to
> add a Breaks line about anyway (see below), so they probably couldn't do
> this if they wanted to.
>
>   
>> However wine should be updated to move to /usr/lib32, because now dpkg does
>> think that wine has its files in /usr/lib32 (but it didn't move the actual
>> files):
>>     
>
> If I understand your report correctly, the Wine package you've installed
> already uses /usr/lib32. If so, the package is *not* broken.
>
> (Perhaps there's a different version now in the archive which might be
> broken, I'm not sure. But yours isn't.)
>
> It is a well-known dpkg problem that it will never automatically convert
> symlinks to directories on upgrade (but blindly follow them). The
> involved packages must therefore use Breaks and Pre-Depends to ensure
> that the directories are fully emptied (i.e., all relevant packages
> uninstalled) before the libc upgrade. Then libc's maintainer scripts can
> delete the old symlink, and then the updated packages can be installed,
> and the files be placed in the new location.
>
> Using Breaks might be tricky in this case, though, since the packages
> *already* used the right paths, and did not need to be changed. Which
> means there's no package version to use Breaks against.
>
> You have a choice of reinstalling the Wine debs (apt-get install
> --reinstall on the affected debs might suffice), or manually moving the
> files around to match the dpkg -L output.
>   

Reinstalling wine and all of its libs makes wine able to start, thanks!

> I'm not sure it's worth it to add maintainer scripts to either libc or
> wine that tries to automate any workarounds, given that the problem is
> only in experimental, and never happened in sid. Hopefully people that
> use experimental know how to fix their systems when it breaks - at least
> know how to reinstall a package.
>
> I will leave the bug open so that other people with similar issues know
> what's going on, but there's no need to fix the package. Thus,
> downgrading to non-RC.
>   

There is something wrong with dependencies now, since ia32-libs doesn't
actually install any of the
32 bit packages it used to, it merely pulls in ia32-apt-get.
It would be nice if there was a package that pulls in everything
ia32-libs used to have, but I can't seem to find one.

So starting 'wine notepad' fails because it can't find libSM.so.6 for
example.

I installed these to get a somewhat usable wine, I don't know if I
missed any libraries:
ia32-libsm6 ia32-libxext6 ia32-libfreetype6

I also noticed that ia32-apt-get created a package called ia32-wine.
Should that one be used now?
(it seems to pull in a lot of ia32- libs as dependencies, which I assume
is good)

However nvidia-glx-ia32 is broken, and there is no ia32-nvidia-glx, so I
manually copied files from /emul to /usr/lib32
(see ,#534873), and now games are working again with wine!

Best regards,
--Edwin





More information about the pkg-wine-party mailing list