Control: forwarded -1 https://bitbucket.org/acoustid/chromaprint/pull-requests/8
Hi, On 28/12/16 00:16, Andreas Cadhalpun wrote: > Control: reassign -1 libchromaprint1 1.4.1-1 > Control: severity -1 serious > > Hi Bill, > > On 27.12.2016 19:06, Bill Allombert wrote: >> There is a circular dependency between libavformat57 and libchromaprint1: >> >> libavformat57 :Depends: libchromaprint1 (>= 1.3.2) >> libchromaprint1 :Depends: libavformat57 (>= 7:3.2.2) >> >> Circular dependencies involving shared libraries are known to cause problems >> during upgrade between stable releases, so we should try to avoid them. > > Thanks for catching that. > > Libavformat uses libchromaprint since version 7:3.0-1, while libchromaprint > started linking libavformat only in the last uploaded version 1.4.1-1. > Previously only libchromaprint-tools used libavformat. > > While it would be easy to disable chromaprint support in ffmpeg, that > would be a feature regression, so I'd rather not do that. > > Hence I'm reassigning this to chromaprint. > As this is not the time in the release cycle to let such issues slip > into testing, I'm raising the severity to serious to prevent testing > migration of the new chromaprint, until this issue is solved. > > Now the question is, why did libchromaprint start using libavformat? > Can this functionality be moved to libchromaprint-tools or at least > be disabled? libchromaprint.so.1 doesn't seem to use any symbols from libavformat, so it should not link to it. I submitted a simple PR upstream to fix it. In the meantime, the Debian package could just link with -Wl,--as-needed to avoid having to patch anything. Thanks, James
signature.asc
Description: OpenPGP digital signature
