libavcodec58 conflicts with libavcodec-extra58 (Linux Mint 20)

[lhriley]

Hello,

I've found that when downloading the oacapture deb from http://www.openastroproject.org/wp-content/uploads/2020/12/ubuntu-20.04-amd64/oacapture_1.8.0-1_amd64.deb the package doesn't account for the libavcodec-extra58 package being installed and wants to remove everything that relies on it. This package extends libavcodec58 and thus conflicts.

I would post a PR that fixes this issue, but I don't really understand the build process for this project and don't know where to start.

However, I've solved this problem by editing the control file and rebuilding the deb locally:

Package: oacapture
Version: 1.8.0-1
Architecture: amd64
Maintainer: James Fidell <james@openastroproject.org>
Installed-Size: 5478
Depends: libavcodec58 (>= 7:4.2) | libavcodec-extra58 (>= 7:4.2), libavformat58 (>= 7:4.2), libavutil56 (>= 7:4.0), libc6 (>= 2.29), libcfitsio8 (>= 3.470~), libftdi1-2 (>= 1.2), libgcc-s1 (>= 3.0), libhidapi-libusb0 (>= 0.8.0~rc1+git20140201.3a66d4e+dfsg), libjpeg8 (>= 8c), libpng16-16 (>= 1.6.2-1), libqt5core5a (>= 5.12.2), libqt5gui5 (>= 5.3.0) | libqt5gui5-gles (>= 5.3.0), libqt5widgets5 (>= 5.0.2), libraw19 (>= 0.19.0), libstdc++6 (>= 5.2), libtiff5 (>= 4.0.3), libudev1 (>= 183), libusb-1.0-0 (>= 2:1.0.9), libv4l-0 (>= 0.5.0)
Section: science
Priority: optional
Homepage: http://www.openastroproject.org/
Description: planetary capture application
 An application and associated tools for controlling cameras for planetary
 capture and related astronomy imaging

Specifically this depends entry:

libavcodec58 (>= 7:4.2) | libavcodec-extra58 (>= 7:4.2)

I'm including the modified deb as a working example. The control file is the only change, but github requires the file be of zip format so you'll need to extract the deb from the zip. oacapture_1.8.0-1a_amd64.deb.zip

Additionally, I would ask if there is the possibility of creating a PPA (https://launchpad.net/) for easier update management. Downloading deb files from a wordpress site isn't exactly the best workflow.

[openastroproject]

I'll look into this. I wonder if Ubuntu 20.04 and Mint 20 have diverged for these libraries. Unexpected, but not impossible I guess.

As regards the PPA, yes, I agree it would be preferable. When I've looked at it in the past it wasn't particularly practical because of the versions of libraries that oacapture is dependent on, but I think that's probably not an issue any more.

[lhriley]

Thanks!

I believe that libavcodec-extra58 might be exclusive to Linux Mint as they have a meta package option that provides extra closed source codecs and drivers.

I haven't used vanilla Ubuntu as a desktop in years, so I'm just assuming this doesn't exist in their repos, though.

[openastroproject]

Easy one first :) Setting up a PPA is on my list of things to do: #75

At the moment I don't see why there's a problem with the libavcodec packages. libavcodec-extra58 appears to say it provides libavcodec58, so I'd have thought that would be sufficient to keep everyone happy. On my Mint 20 machine I have libavcodec-extra58 installed and therefore no libavcodec58, but the oacapture package installs without a problem. I can't immediately see why it wouldn't work for you.

[lhriley]

Easy one first :) Setting up a PPA is on my list of things to do: #75

Sweet, thanks :dog::+1:

At the moment I don't see why there's a problem with the libavcodec packages. libavcodec-extra58 appears to say it provides libavcodec58, so I'd have thought that would be sufficient to keep everyone happy. On my Mint 20 machine I have libavcodec-extra58 installed and therefore no libavcodec58, but the oacapture package installs without a problem. I can't immediately see why it wouldn't work for you.

Hmm. That's very odd. Is this a fresh install of Mint 20? I just removed the package that I modified and reinstalled the one I had originally downloaded. I'm including a screenshot of the conflicts presented by gdebi. As you can see, the conflict is with libavcodec58 and everything being removed requires it.

I agree that it should just work as is, especially given the fact that the extra package explicitly provides the standard package. I'm including the apt info of the version I have installed in case there might be a difference you can spot:

> apt show libavcodec-extra58
Package: libavcodec-extra58
Version: 7:4.2.4-1ubuntu0.1
Priority: optional
Section: universe/libs
Source: ffmpeg
Origin: Ubuntu
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Debian Multimedia Maintainers <debian-multimedia@lists.debian.org>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 14.6 MB
Provides: libavcodec58 (= 7:4.2.4-1ubuntu0.1)
Depends: libaom0 (>= 1.0.0), libaribb24-0 (>= 1.0.3), libavutil56 (= 7:4.2.4-1ubuntu0.1), libc6 (>= 2.29), libcairo2 (>= 1.2.4), libcodec2-0.9, libglib2.0-0 (>= 2.12.0), libgsm1 (>= 1.0.18), liblzma5 (>= 5.1.1alpha+20120614), libmp3lame0 (>= 3.100), libopencore-amrnb0 (>= 0.1.5), libopencore-amrwb0 (>= 0.1.5), libopenjp2-7 (>= 2.0.0), libopus0 (>= 1.1), librsvg2-2 (>= 2.14.4), libshine3 (>= 3.1.0), libsnappy1v5 (>= 1.1.8), libspeex1 (>= 1.2~beta3-1), libswresample3 (= 7:4.2.4-1ubuntu0.1), libtheora0 (>= 1.0), libtwolame0 (>= 0.3.10), libva2 (>= 2.2.0), libvo-amrwbenc0 (>= 0.1.3), libvorbis0a (>= 1.1.2), libvorbisenc2 (>= 1.1.2), libvpx6 (>= 1.6.0), libwavpack1 (>= 4.40.0), libwebp6 (>= 0.5.1), libwebpmux3 (>= 0.6.1-2), libx264-155, libx265-179 (>= 3.2), libxvidcore4 (>= 1.2.2), libzvbi0 (>= 0.2.35), zlib1g (>= 1:1.2.0)
Conflicts: libavcodec58
Homepage: https://ffmpeg.org/
Download-Size: 4,880 kB
APT-Manual-Installed: no
APT-Sources: http://la-mirrors.evowise.com/ubuntu focal-updates/universe amd64 Packages
Description: FFmpeg library with additional de/encoders for audio/video codecs
 FFmpeg is the leading multimedia framework, able to decode, encode, transcode,
 mux, demux, stream, filter and play pretty much anything that humans and
 machines have created. It supports the most obscure ancient formats up to the
 cutting edge.
 .
 This library provides a generic encoding/decoding framework and
 contains multiple decoders and encoders for audio, video and subtitle streams,
 and several bitstream filters.
 .
 The shared architecture provides various services ranging from bit stream I/O
 to DSP optimizations, and makes it suitable for implementing robust and fast
 codecs as well as for experimentation.
 .
 This package replaces the libavcodec58 package and contains the
 following additional codecs:
 .
  * ARIB STD-B24 Captions (Subtitle Decoder)
  * OpenCORE Adaptive Multi-Rate (AMR) Narrow-Band (Encoder/Decoder)
  * OpenCORE Adaptive Multi-Rate (AMR) Wide-Band (Decoder)
  * Android VisualOn Adaptive Multi-Rate (AMR) Wide-Band (Encoder)
 .
 Because this package links against libraries that are licensed under
 Apache License 2.0, the resulting binaries are distributed under the
 GPL version 3 or later.

N: There is 1 additional record. Please use the '-a' switch to see it

[openastroproject]

That's near identical to what I have. The only obvious difference is the download source (APT-Sources).

I see no reason why it should make a difference, but can you see if you get the same error when installing it from the command line using "dpkg -i"?

[lhriley]

dpkg installs without any apparent issue. I believe that this is probably due to dpkg being a lot less "intelligent" about dependency management. In my experience you would typically run something like sudo apt install -f after a dpkg install to ensure that dependencies have been met.

It looks like gdebi is doing this automagically by mixing dpkg and apt installs behind the scenes according to this answer: https://askubuntu.com/a/813455/128241

I'm still not sure why gdebi sees a conflict, though, since the libavcodec packages provide the same resources. I can't seem to find any related discussions on this particular problem, but I didn't do an exhaustive search.

For reference this is my dpkg output:

> sudo dpkg -i ./oacapture_1.8.0-1_amd64.deb
Selecting previously unselected package oacapture.
(Reading database ... 472041 files and directories currently installed.)
Preparing to unpack ./oacapture_1.8.0-1_amd64.deb ...
Unpacking oacapture (1.8.0-1) ...
Setting up oacapture (1.8.0-1) ...
Processing triggers for gnome-menus (3.36.0-1ubuntu1) ...
Processing triggers for desktop-file-utils (0.24+linuxmint1) ...
Processing triggers for mime-support (3.64ubuntu1) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...

[openastroproject]

If I try "apt install ./oacapture_1.8.0-1_amd64.deb" then that also works for me.

I'm inclined to think this is actually a gdebi bug that causes it to ignore the "Provides" settings for packages. I struggle to believe it, but I can't see any other plausible explanation for the moment.

[lhriley]

Hmm. I'd have to agree that this is probably a gdebi exclusive issue. There has to be some way to solve this, though, as I don't think I've seen this issue with any other packages that I've installed with gdebi.

For reference, I happened upon a couple of bug reports that seem related.

This one was opened in 2014, and is present in gdebi-core. Unfortunately, I haven't been able to find any discussion on this bug report, so I don't know what the current status might be. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736343

This one was initially opened against python-apt in 2007 and has been reported as both fixed over a decade ago and reproduced in the last 6 months. https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/146398

I'm actually quite surprised that issues like this would exist in such a commonly used package installer, especially one that has been around for as long as this.