[FFmpeg-devel] [RFC] libavutil split out

[Timo Rothenpieler]

On 31.10.2024 01:08, Michael Niedermayer wrote:
> Hi
> 
> Theres a problem with libavutil, or maybe more than one
> 
> a library implementing a codec that tries do use libavutil and itself is
> used by libavcodec. Creates a (build) dependancy like this
> libavutil -> libmycodec -> libavcodec
> Thats ok if libavutil is a seperate source but if libavutil and libavcodec
> are in the same source package and are build together, well iam sure
> you see this doesnt work
> build ffmpeg first, theres no libmycodec,
> build libmycodec first, theres no libavutil
> now of course this can be worked around by building ffmpeg twice
> But this is not documented, not suggested, not tested and not considered
> 
> of course myself spliting out libpostproc made me realize this issue. But
> its a much broader problem than libpostproc. For libpostproc i can just
> copy everything and remove all libavutil dependancies
> And even without that it builds and works fine and all but only because i had
> a prior build libavutil installed from before.
> 
> And thats not a freak exception, the same issue happens with a demuxer
> lib trying to use libavutil or a device lib trying to use libavutil
> or a filter trying to use libavutil.
> They all need libavutil built first,
> 
> And i think we do want people to use libavutil, if for no other reason
> than easy sharing of things like AV_PIX_FMT and other enums and defines
> or the ability to pass AVFrames or reference stuff around with no wraping
> 
> So what do people prefer ?
> Should we just docuemnt that packagers of distros should consider
> building libavutil in s stage1 and the then everything else in a stage2
> so they avoid circular dependancies

At least on Gentoo, which is one of the few distros where this is 
actually an issue at the distro level, it's relatively common practice 
to first build a package in a smaller version, to then install 
components that use it, which later can become a dependency of the 
package itself when it gets rebuilt next time.

On binary distros libavutil can be easily split into its own package, 
and is even often done so already.

So this definitely seems like the way that causes the least amount of 
disruption.