Gstreamer-plugins-bad on multiarch installation

[dnord]

I try to have installed both

Code: Select all

gstreamer1.0-plugins-bad gstreamer1.0-plugins-bad:i386

packages on multiarch installation of Debian Stretch, but whenever one is installing second gets deleted by package manager. I do not have this problem with other i386 packages and plugins -ugly, -good from gstreamer, only with -bad. It looks like their dependencies

Code: Select all

libmjpegutils-2.1-0 libmjpegutils-2.1-0:i386

cannot be installed simultaneously for some reason, as I get message:

Code: Select all

# apt install  libmjpegutils-2.1-0:i386 libmjpegutils-2.1-0
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libmjpegutils-2.1-0 : Conflicts: libmjpegutils-2.1-0:i386 but 1:2.1.0+debian-5 is to be installed
 libmjpegutils-2.1-0:i386 : Conflicts: libmjpegutils-2.1-0 but 1:2.1.0+debian-5 is to be installed
E: Unable to correct problems, you have held broken packages.

But I cannot find reason for this conflict - there are no mentions like "breaks" or "conflicts" in package's description, so I'm confused why this conflict is happening.

Is it intended behavior or packaging error? Are these packages intended to be installed simultaneously?

[Head_on_a_Stick]

Apparently, they are not co-installable:

Code: Select all

TheLab: ~ # aptitude why-not libmjpegutils-2.1-0:i386
i   gstreamer1.0-plugins-bad Depends   libmjpegutils-2.1-0     
i A libmjpegutils-2.1-0      Conflicts libmjpegutils-2.1-0:i386

You should probably post the full output of `apt-cache policy` though, just in case.

Digging a little more, the i386 version of libmjpegutils depends on libc6 2.11 whereas the amd64 variant needs 2.14 or newer -- this is probably why.

https://packages.debian.org/jessie/libmjpegutils-2.1-0

[pendrachken]

Apparently, they are not co-installable:

Code: Select all

TheLab: ~ # aptitude why-not libmjpegutils-2.1-0:i386
i   gstreamer1.0-plugins-bad Depends   libmjpegutils-2.1-0     
i A libmjpegutils-2.1-0      Conflicts libmjpegutils-2.1-0:i386

You should probably post the full output of `apt-cache policy` though, just in case.

Digging a little more, the i386 version of libmjpegutils depends on libc6 2.11 whereas the amd64 variant needs 2.14 or newer -- this is probably why.

https://packages.debian.org/jessie/libmjpegutils-2.1-0

Sounds like a broken package to me. i386 depends on libc6 greater than 2.11, and amd64 depends on libc6 greater than 2.14, this is in both stable and testing. libc6 in jessie is 2.19 (2.24 in stretch, which OP is trying to install from ). There should not be any problems installing them side by side in multiarch systems, unless the built package has unnecessary conflicts put in at build time, or only have a partial dependency chain. Either way, seems like a mistake on the part of the packager / maintainer, and is a bug that should be reported.

The OP seems to be entirely correct in saying that the conflicts should not be happening. Both of them have libc6 fulfilled to meet dependencies, and should be co-install-able.

[dnord]

Apparently, they are not co-installable:

Code: Select all

TheLab: ~ # aptitude why-not libmjpegutils-2.1-0:i386
i   gstreamer1.0-plugins-bad Depends   libmjpegutils-2.1-0     
i A libmjpegutils-2.1-0      Conflicts libmjpegutils-2.1-0:i386

You should probably post the full output of `apt-cache policy` though, just in case.

Digging a little more, the i386 version of libmjpegutils depends on libc6 2.11 whereas the amd64 variant needs 2.14 or newer -- this is probably why.

https://packages.debian.org/jessie/libmjpegutils-2.1-0

Code: Select all

# apt-cache policy
Package files:
 100 /var/lib/dpkg/status
     release a=now
 500 http://httpredir.debian.org/debian stretch/contrib i386 Packages
     release o=Debian,a=testing,n=stretch,l=Debian,c=contrib,b=i386
     origin httpredir.debian.org
 500 http://httpredir.debian.org/debian stretch/contrib amd64 Packages
     release o=Debian,a=testing,n=stretch,l=Debian,c=contrib,b=amd64
     origin httpredir.debian.org
 500 http://httpredir.debian.org/debian stretch/main i386 Packages
     release o=Debian,a=testing,n=stretch,l=Debian,c=main,b=i386
     origin httpredir.debian.org
 500 http://httpredir.debian.org/debian stretch/main amd64 Packages
     release o=Debian,a=testing,n=stretch,l=Debian,c=main,b=amd64
     origin httpredir.debian.org
Pinned packages:

I have no problems with libc6. libmjpegutils-2.1-0 could be installed, but libmjpegutils-2.1-0:i386 gets deleted and vice-versa but no other package are touched in the process. Could it be some obscure multiarch problem? The only external difference I noticed is that for libs without this problem packages have Pre-Depends: multiarch-support line in package information. Not sure what it mean, but it seems that maintainer should take some special measures to get multiarch support. I read somewhere that multiarch support in Debian is still incomplete, maybe someone knows better?

[dnord]

I think I found out reason. apt-cache show libmjpegutils-2.1-0 shows no multi-arch field which results in conflict, while it should be

Code: Select all

Multi-Arch: same

It could be added safely as library already uses path like /usr/lib/i386-linux-gnu/. Unfortunately there are still more libraries without multiarch support like libsrtp0 libzbar0 liblilv-0-0 which use /usr/lib directly, so I still cannot install gstreamer plugins. Are there any chances to push maintainers to repack them and add multiarch support?

[pendrachken]

Download the source and build-deps, patch up the debian control files to have the dependencies and proper "provides" fields you need, and have apt build you debs.


As for maintainers, look for a bug report against the packages for this issue, and if there are none file a report so the maintainers know they need to change the builds.

[dnord]

https://bugs.debian.org/cgi-bin/bugrepo ... bug=765173
https://bugs.debian.org/cgi-bin/bugrepo ... bug=777202
Looks like maintainers do not care much.