Bug#904163: ffmpeg: investigate the use of versioned provides in place of the alternative dependencies in shlibdeps

James Cowgill jcowgill at debian.org
Tue Jul 31 05:34:17 BST 2018


Hi,

On 23/07/18 20:05, Reinhard Tartler wrote:
> ​Thanks for looking into this.
> 
> If the infrastructure is in place for this now, and there are upsides
> with this approach then I agree that this should be evaluated, and the
> results documented in this ticket. The thing is, I'm not sure I
> understand the upsides.

I've created this MR which implements this. Feel free to test it :)
https://salsa.debian.org/multimedia-team/ffmpeg/merge_requests/2

> Discoverability is indeed a concern. How are users supposed to know what
> to install in order to get the extra functionality? Will meta-packages
> (think libavcodec-extra) help with picking up the right package? Does
> this also work for package upgrades, or are there situations where APT
> might prefer to remove the -extra variants in favor for base variant?

I think the discoverability issue Mattia mentioned is not applicable
here because we're providing another concrete package? The meta-packages
have not changed, so installing the -extra variants works the same way
as it currently does. I've done some basic testing of upgrades and APT
seems to do the right thing. I haven't tested any complex situations though.

> My main concern with this proposal is the motivation behind it: To
> support 3rd party packages that have been compiled against a version of
> ffmpeg that is NOT found in Debian. I don't think this is something we
> should encourage. In the past, people have asked for help with the
> ffmpeg package and our reply is typically to replace 3rd party packages
> with the version found in Debian, which is frustrating, time-consuming
> and not in anyone's interest.

I have in fact been thinking about using versioned provides for some
time here because it seemed like the "correct" way to do it. The
advantages are mostly limited to simpler dependencies in rdeps. It also
has the small advantage of not requiring a package transition if an
-extra variant is added (although there are no plans for that).

I agree we should not encourage compiling debs against ffmpeg without
using the correct tools / packages. I don't think the fact that
implementing this would "help" people break the rules should count as a
negative point though.

> ​Dirk, I think the right course of action to get your jitsi backport
> working is to contact the supplier of the jitsi package, and ask them to
> recompile the package without the use of 3rd party package
> archives. Feel free to point them to this email.

For this specific situation this is the best thing to do. Also note that
when this bug is fixed, your issue won't be resolved because the package
would need recompiling for FFmpeg 4.0 anyway.

James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-multimedia-maintainers/attachments/20180731/557be621/attachment.sig>


More information about the pkg-multimedia-maintainers mailing list