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
signature.asc
Description: OpenPGP digital signature
