Re: [multiarch] easy fix for interarchitectural package conflict?

On Mon, May 5, 2014 at 6:10 AM, Tom Roche <Tom_Roche@pobox.com> wrote:

https://lists.debian.org/debian-user/2014/05/msg00291.html [Tom Roche Sun, 04 May 2014 16:04:30 -0400]

>> me@it ~ $ inxi -r
>> Repos: Active apt sources in file: /etc/apt/sources.list.d/google-chrome.list
>> deb http://dl.google.com/linux/chrome/deb/ stable main
>> Active apt sources in file: /etc/apt/sources.list.d/official-package-repositories.list
>> deb http://packages.linuxmint.com debian main upstream import
>> deb http://debian.linuxmint.com/latest/ testing main contrib non-free
>> deb http://debian.linuxmint.com/latest/security testing/updates main contrib non-free
>> deb http://debian.linuxmint.com/latest/multimedia testing main non-free
>> deb http://extra.linuxmint.com debian main

>> me@it ~ $ sudo aptitude -s install icedtea-7-plugin:i386

...

>> The following packages have unmet dependencies:
>> libgif4 : Conflicts: libgif4:i386 but 4.1.6-10 is to be installed.
>> libgif4:i386 : Conflicts: libgif4 but 4.1.6-10 is installed.

https://lists.debian.org/debian-user/2014/05/msg00294.html [Sven Joachim Sun, 04 May 2014 22:21:45 +0200]
> [you have an] older version of libgif4 than the one in jessie/sid[,
> since] Multiarch support was enabled in 4.1.6-11 back in December 2013.

So how to get a multiarch version of libgif4? My guess is, the sequence

1. add a repository
2. update packages
3. update package=libgif4:i386
4. install package=icedtea-7-plugin:i386
5. remove repository

... is that correct? If so, which repo to add? My guess is

deb http://ftp.debian.org/debian/ testing main contrib non-free

No?

TIA, Tom Roche <Tom_Roche@pobox.com>

If you really have the time to keep diddling with things that are, really, counter to the direction the developers are headed, try it and see.

But you keep saying you want to get back to your paying job.

I know the thrill of the hunt, and I myself tend to live outside the mainstream far too much, but you really need to ask yourself why you are avoiding using a vm to run the 32-bit stuff.

Sure, you need to check whether your 64-bit cpu/chipset/motherboard will support the vm approach of your choice, and check your free RAM and HD and such, and you're faced with a separate install of a fairly full 32-bit system that will run in the vm, and you have the question of whether to start with wheezy or squeeze (or the current stable mint?) in the vm, etc. But it will leave you with a more stable solution.

And it will be easier to work with the knuckle-headed sysadmins at work when they finally give in and decide the security issues require them to update their VPN infrastructure.

--
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.