I forgot to mention, I have this built in a copr repo, along with the updated ffmpeg, and other packages that need want the updated ffmpeg.
https://copr.fedorainfracloud.org/coprs/tdawson/epel9-next-ffmpeg/

Copr build:
https://copr.fedorainfracloud.org/coprs/build/10861797
(failed)

Build log:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2514855-ffmpeg5/fedora-rawhide-x86_64/10861797-ffmpeg5/builder-live.log.gz

Please make sure the package builds successfully at least for Fedora Rawhide.

- If the build failed for unrelated reasons (e.g. temporary network
  unavailability), please ignore it.
- If the build failed because of missing BuildRequires, please make sure they
  are listed in the "Depends On" field


---
This comment was created by the fedora-review-service
https://github.com/FrostyX/fedora-review-service

If you want to trigger a new Copr build, add a comment containing new
Spec and SRPM URLs or [fedora-review-service-build] string.

This build is not meant to build on Rawhide.  The various patches are meant to allow it to build on epel9, which it does.

The configure step has the --disable-doc flag, but then later ffmpeg5-free-devel includes several files marked as docs.  Should those files be skipped as well?

================================================================================

I noticed that the ffmpeg5-free subpackage is almost empty.  With the ffmpeg, ffplay, and ffprobe commands disabled, it only contains CREDITS, README.md, and an empty /usr/share/ffmpeg5 directory. Does it make sense to keep that subpackage?  Installing it does pull in all the library subpackages, but users might be confused if they install ffmpeg5-free and don't have the ffmpeg command.

================================================================================

Some compat packages keep their devel subpackages so that other packages can still build against them.  Other compat packages remove their devel subpackages to prevent this, sending a clear signal that the library is strictly for satisfying existing packages' dependencies and shouldn't be used for new builds.  Do you want to allow other packages to continue building against ffmpeg5 libraries?

================================================================================

The subpackages with shared libraries need to conflict with the equivalent non-compat subpackage with the same soname.  The easiest way to do that is to conflict with the soname itself.  Here's an example for how to do it for libavcodec5-free (along with a corresponding comment suggestion).

    # This compat package cannot be installed at the same time as the base package
    # of the same soname version due to file conflicts.  Different soname versions
    # can be installed in parallel.
    %ifarch armv7hl i686
    Conflicts: libavcodec.so.%{av_codec_soversion}
    %else
    Conflicts: libavcodec.so.%{av_codec_soversion}()(%{__isa_bits}bit)
    %endif

The devel subpackages (if you keep them) also need to conflict with the equivalent non-compat devel subpackages.  The easiest way to do that is to conflict with the pkgconfig name.

    # This compat devel package cannot be installed at the same time as the base
    # devel package due to file conflicts, regardless of soname version.
    Conflicts: pkgconfig(libavcodec)

================================================================================

Currently the subpackages follow the pattern of adding the compat version as a suffix after the subpackage name.

    %package -n libavcodec5%{?pkg_suffix} -> libavcodec5-free

This isn't wrong per se, but I think it is worth considering a different approach.

    %package libavcodec%{?pkg_suffix} -> ffmpeg5-libavcodec-free

In compat packages I've maintained before doing the former approach ended up being confusing.  I like the mapping of "this is libavcodec, from ffmpeg5" personally.  It's a subjective thing, but I wanted to bring it up as an alternative in case you like it.

(In reply to Carl George 🤠 from comment #4)
> The configure step has the --disable-doc flag, but then later
> ffmpeg5-free-devel includes several files marked as docs.  Should those
> files be skipped as well?
> 
> =============================================================================
> ===
> 
> I noticed that the ffmpeg5-free subpackage is almost empty.  With the
> ffmpeg, ffplay, and ffprobe commands disabled, it only contains CREDITS,
> README.md, and an empty /usr/share/ffmpeg5 directory. Does it make sense to
> keep that subpackage?  Installing it does pull in all the library
> subpackages, but users might be confused if they install ffmpeg5-free and
> don't have the ffmpeg command.
> 
> =============================================================================
> ===

I was debating back and forth on this.  The reason I left some of the docs was because I still had the ffmpeg5 package.
But I see your point that it can be confusing.  I will take out the ffmpeg5 package, which should remove the rest of the docs.

(Note: I'm not dismissing the rest of your comments, I'm just doing them a portion at a time.)

> Some compat packages keep their devel subpackages so that other packages can
> still build against them.  Other compat packages remove their devel
> subpackages to prevent this, sending a clear signal that the library is
> strictly for satisfying existing packages' dependencies and shouldn't be
> used for new builds.  Do you want to allow other packages to continue
> building against ffmpeg5 libraries?
> 

Thank you for pointing this out, but I will be keep the -devel packages.

Both blender and gstreamer1-plugin-libav were not able to update to ffmpeg7 due to different reasons.
It is possible they either of them will need to rebuild for CVE's.  Thus they will need the -devel packages.

(In reply to Carl George 🤠 from comment #4)
> 
> The subpackages with shared libraries need to conflict with the equivalent
> non-compat subpackage with the same soname.  The easiest way to do that is
> to conflict with the soname itself.  Here's an example for how to do it for
> libavcodec5-free (along with a corresponding comment suggestion).
> 
>     # This compat package cannot be installed at the same time as the base
> package
>     # of the same soname version due to file conflicts.  Different soname
> versions
>     # can be installed in parallel.
>     %ifarch armv7hl i686
>     Conflicts: libavcodec.so.%{av_codec_soversion}
>     %else
>     Conflicts: libavcodec.so.%{av_codec_soversion}()(%{__isa_bits}bit)
>     %endif
> 
> The devel subpackages (if you keep them) also need to conflict with the
> equivalent non-compat devel subpackages.  The easiest way to do that is to
> conflict with the pkgconfig name.
> 
>     # This compat devel package cannot be installed at the same time as the
> base
>     # devel package due to file conflicts, regardless of soname version.
>     Conflicts: pkgconfig(libavcodec)
> 

Thank you.
I knew there needed to be some conflict, but didn't know what was the correct way to do it.

> =============================================================================
> ===
> 
> Currently the subpackages follow the pattern of adding the compat version as
> a suffix after the subpackage name.
> 
>     %package -n libavcodec5%{?pkg_suffix} -> libavcodec5-free
> 
> This isn't wrong per se, but I think it is worth considering a different
> approach.
> 
>     %package libavcodec%{?pkg_suffix} -> ffmpeg5-libavcodec-free
> 
> In compat packages I've maintained before doing the former approach ended up
> being confusing.  I like the mapping of "this is libavcodec, from ffmpeg5"
> personally.  It's a subjective thing, but I wanted to bring it up as an
> alternative in case you like it.

I like your way of doing it better.  I have changed that.

Spec URL: https://tdawson.fedorapeople.org/review/ffmpeg5/ffmpeg5.spec
SRPM URL: https://tdawson.fedorapeople.org/review/ffmpeg5/ffmpeg5-5.1.9-2.el10.src.rpm

I have:
- Removed ffmpeg5 and ffmpeg5-devel subpackages
- Removed all the docs other than the licenses
- Renamed the remaining subpackages so they are ffmpeg5-<variant>-free
- For the devel added Conflicts: pkgconfig(<variant>)
- For the libraries added Conflicts, as you have stated above.

I have also tested these using the copr repo listed above.
- I am able to install new and compat libraries at the same time.
- I cannot install both the new and compat -devel packages at the same time
- I can install packages that need the new libaries at the same time as I install packages that require the compat libraries, and all the proper libraries are installed.

This all looks great, thanks for making those changes.

To the extent I can approve a package review for a compat package that qualifies for a review exception, package APPROVED.

Thank you for your help on this.  This was my first compat package so I wasn't totally sure what I was doing.  Your comments and suggestions were very helpful.

The Pagure repository was created at https://src.fedoraproject.org/rpms/ffmpeg5
Monitoring:
Wasn't able to create project in Anitya. You can create it manually on: `https://release-monitoring.org`