On 2020-01-03 01:08:14, James Cowgill wrote: > Hi, > > On 06/12/2019 03:33, Steve Langasek wrote: > > Package: ffmpeg > > Version: 7:4.2.1-2 > > Severity: minor > > Tags: patch > > User: ubuntu-de...@lists.ubuntu.com > > Usertags: origin-ubuntu focal ubuntu-patch > > > > Dear maintainers, > > > > In Ubuntu, we are in the process of moving the i386 architecture to a > > compatibility-only layer on amd64, and therefore we are also moving our > > autopkgtest infrastructure to test i386 binaries in a cross-environment. > > > > This requires changes to some tests so that they are cross-aware and can do > > the right thing. > > [...] > > > > --- ffmpeg-4.2.1/debian/tests/control 2019-11-01 18:17:31.000000000 > > -0700 > > +++ ffmpeg-4.2.1/debian/tests/control 2019-12-05 17:17:44.000000000 > > -0800 > > @@ -5,4 +5,4 @@ > > Depends: ffmpeg > > > > Tests: encdec-extra > > -Depends: ffmpeg, libavcodec-extra > > +Depends: ffmpeg, libavcodec-extra58 > > Am I right in thinking this is necessary because libavcodec-extra is an > "arch all multi-arch foreign" package? > > I'm wondering if marking libavcodec-extra (and libavfilter-extra) like > that is wrong because the behavior of these packages depends on what the > native architecture is, but I'm not sure. It currently installs the > native arch's libavcodec-extra library which doesn't seem right for a > multi-arch foreign package. I don't know if anyone from the multimedia > team knows why it's done this way (maybe just historical)? > > Making the package "arch any multi-arch same" seems sensible to me, or > just removing the packages altogether (we already have a Provides: > libavcodec-extra on the real library packages so the existing > dependencies should work still).
The package is intended for users that want the extra codecs. So converting it to arch any would be fine, dropping it not. Best > > Thanks, > James > -- Sebastian Ramacher