On Sun, May 7, 2017 at 4:45 PM, Doug Newgard <scimmia@xxxxxxxxxxxxxx> wrote: > On Sun, 7 May 2017 16:36:43 +0000 > Carsten Mattner via arch-general <arch-general@xxxxxxxxxxxxx> wrote: > >> On Sun, May 7, 2017 at 3:01 PM, Doug Newgard <scimmia@xxxxxxxxxxxxxx> wrote: >> > On Sun, 7 May 2017 14:51:08 +0000 >> > Carsten Mattner via arch-general <arch-general@xxxxxxxxxxxxx> wrote: >> > >> >> For various reasons like missing features and wrong version >> >> I cannot use arch's ffmpeg package and have to build my own >> >> package, and this results in a cyclic dependency I cannot >> >> get out of. >> > >> > What, exactly, is the issue here? You need an ffmpeg package that >> > provides what x264 needs, nothing more. >> >> I cannot install libx264's include/x264.h without installing x264 >> which then depends on ffmpeg which itself depends on libx264. >> This doesn't look like a hard cycle since it seems like only >> the x264 executable needs libav*.so, but since x264.h was in >> libx264 (and is in extra still), I've been building a custom >> ffmpeg package without also having to build a custom configured >> (lib)x264 too. > > So what? None of that should cause a problem if your custom > ffmpeg package is done correctly. I have to override/repackage two packages now that x264.h is in a package which leads me into a cycle. Or I repackage ffmpeg, x264, libx264 locally, not just ffmpeg as before. I respect your decision, but I can't find the justification. (lib)x264 packaging has been problematic due to 8bit/10bit in the past as well and I'm certain it's not an easy package to be responsible for. In fact I remember that the header moved around in the packages once before (maybe 2 years ago). x264's new feature flag to depend on libav* is recent and is the source of the cycle.
