On May 12, 2019, at 4:14 PM, Reimar Döffinger <[email protected]> wrote: > > On Sun, May 12, 2019 at 12:07:42PM -0700, Tim Jones wrote: >> On May 12, 2019, at 11:54 AM, Nicolas George <[email protected]> wrote: >>> >>> Tim Jones (12019-05-12): >>> >>>> --disable-all-proprietary/--enable-all-proprietary >>> >>> As for this one, on the other hand, there will be opposition: we do not >>> want encourage users to use proprietary software. In fact, there is >>> currently a discussion to refuse including new proprietary components, >>> and possibly getting rid of the ones we included without thinking. >> >> I don't want to start a thread war here, but isn't the purpose of any >> toolchain to allow for the support of a given task? If there isn't a FOSS >> option and an easily obtained proprietary solution exists, why block it? >> >> This is one of the things I hear from new Linux users when running into the >> FOSS vs. proprietary brick walls - they just want a platform that works. >> The FUD that is continuously promoted concerning adding non-FOSS components >> - Nvidia drivers, ATTO drivers, HighPoint drivers, custom audio device >> drivers - has caused a number of potentially large Linux opportunities to >> move to Windows. >> >> I've long been a proponent of FOSS where it is apropos, but I also >> understand Heinlein's TNSTAAFL :) . > > Well, which is a fairly good argument to enable proprietary components > only in specific cases.
Which is why I asked in my original question if an optional config setting had been discussed previously. If autodetection is an issue "in general", then the option should be to --disable-external, or my --disable-all-proprietary, by default. This flag could then be reversed by the builder to include any external/proprietary libraries found with the understanding that if something is broken, the builder must revert to the --disable-external config and rebuild before attempting to report a bug or other problem. Then it would be up to the builder to determine which of their external features/libraries were causing the build failure or problem. We do this with a few sensor-specific library collections I work with on the Arduino and Raspberry Pi platforms. The user builds with the defaults - if it works, add their custom sensor packages. If it breaks, report that to the creator of your custom sensor module package instead of the upstream team. Works perfectly in each case and the primary team doesn't have to worry about that new hydrology sensor that has added salinity levels to the mix (which we don't even know about). -- Tim _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
