I've recently built OCIO for 10.2 but not opposed to building for 10.1.

+1

+1 overall, with a strong preference to adding the compat package in the same update for a smooth transition for anything outside of EPEL that links against the library.

The compat package should be named yaml-cpp0.7, not yaml-cpp-0.7. The naming guidelines state that the version must be appended directly with no separator.

If you only want the compat package to provide the library for existing packages, but not allow new builds against it, you can drop the devel and static subpackages. If you keep those, be aware of the compat conflicts exception to keep the files in the normal locations.

My proposed compat package:

%global sover 0.7
%global srcname yaml-cpp
Name:           yaml-cpp%{sover}
Version:        0.7.0
Release:        1%{?dist}
License:        MIT
Summary:        A YAML parser and emitter for C++
URL:            https://github.com/jbeder/yaml-cpp
Source0:        %{url}/archive/%{srcname}-%{version}/%{srcname}-%{version}.tar.gz
# CMake fixes from 0e6e28d1a38224fc8172fae0109ea7f673c096db commit
Patch100:       yaml-cpp-cmake.patch
BuildRequires:  cmake
BuildRequires:  gcc
BuildRequires:  gcc-c++
BuildRequires:  make
%description
yaml-cpp is a YAML parser and emitter in C++ written around the YAML 1.2 spec.
%package        devel
Summary:        Development files for %{name}
Requires:       %{name}%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release}
Requires:       libstdc++-devel%{?_isa}
Conflicts:      %{srcname}-devel
%description    devel
The %{name}-devel package contains libraries and header files for
developing applications that use %{name}.
%package        static
Summary:        Static library for %{name}
Requires:       %{name}-devel%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release}
Conflicts:      %{srcname}-static
%description    static
The %{name}-static package contains the static library for %{name}.
%prep
%autosetup -n %{srcname}-%{srcname}-%{version} -p1
%build
%cmake -B build_static \
    -DCMAKE_BUILD_TYPE=Release \
    -DYAML_CPP_BUILD_TOOLS:BOOL=OFF \
    -DYAML_CPP_FORMAT_SOURCE:BOOL=OFF \
    -DYAML_CPP_INSTALL:BOOL=ON \
    -DYAML_BUILD_SHARED_LIBS:BOOL=OFF \
    -DYAML_CPP_BUILD_TESTS:BOOL=OFF
%make_build -C build_static
%cmake -B build_shared \
    -DCMAKE_BUILD_TYPE=Release \
    -DYAML_CPP_BUILD_TOOLS:BOOL=OFF \
    -DYAML_CPP_FORMAT_SOURCE:BOOL=OFF \
    -DYAML_CPP_INSTALL:BOOL=ON \
    -DYAML_BUILD_SHARED_LIBS:BOOL=ON \
    -DYAML_CPP_BUILD_TESTS:BOOL=OFF
%make_build -C build_shared
%install
%make_install -C build_static yaml-cpp
# Move files so they don't get trampled
mv %{buildroot}%{_libdir}/cmake/%{srcname} \
    %{buildroot}%{_libdir}/cmake/%{srcname}-static
mv %{buildroot}%{_libdir}/pkgconfig/%{srcname}.pc \
    %{buildroot}%{_libdir}/pkgconfig/%{srcname}-static.pc
%make_install -C build_shared
%files
%doc CONTRIBUTING.md README.md
%license LICENSE
%{_libdir}/lib%{srcname}*.so.%{sover}*
%files devel
%{_includedir}/yaml-cpp/
%{_libdir}/lib%{srcname}.so
%{_libdir}/cmake/%{srcname}
%{_libdir}/pkgconfig/%{srcname}.pc
%files static
%license LICENSE
%{_libdir}/lib%{srcname}.a
%{_libdir}/cmake/%{srcname}-static
%{_libdir}/pkgconfig/%{srcname}-static.pc
%changelog
* Tue Dec 02 2025 Orion Poplawski - 0.7.0-1
- Initial compatibility packge

I've requested the repo here: https://pagure.io/releng/fedora-scm-requests/issue/79886

That spec file will have an implicit conflict with the existing version of yaml-cpp, which could lead to installation problems if a user installs it without upgrading yaml-cpp to the new 0.8 version in the same transaction. I recommend making the conflict explicit to help dnf do the right thing.

# 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:      libyaml-cpp.so.%{sover}
%else
Conflicts:      libyaml-cpp.so.%{sover}()(%{__isa_bits}bit)
%endif

We discussed this today at the EPEL Steering Committee meeting. This was approved unanimously on two conditions:

• the compat package is shipped at the same time as the incompat update
• the update is done in EPEL 10.2 first to ensure it works as expected before doing it in EPEL 10.1

Please proceed.

Okay, i've checked in and am building yaml-cpp0.7-0.7.0-1.el10_2 (https://koji.fedoraproject.org/koji/taskinfo?taskID=139672321) with Carl's conflict suggestion. I've added @hobbes1069 as an admin to that package as well.

Now we need 0.8 built in epel10. I can do that as a PP, or Richard can do it since he seems to have expressed interest.

Then we just need the two builds bundled into a single update which either of us should be able to do.

Richard - let me know how you want to proceed.

Thank you everyone for your support.

Happy to do it, but i have maybe an hour at most for packaging a day (minus weekends) so if you want to go ahead. Is the plan a side tag or buildroot override?

We should be proper and do a side tag for the 0.8 update. @tdawson mentioned a qt update to coordinate with.

I see that yaml-cpp0.7-0.7.0-1.el10_2 has been built, but not in a side tag. Once the side tag is created you can tag it in so that it's included in the same update. Please make sure to not submit it in a separate update, as that could result in yaml-cpp0.7 and yaml-cpp moving to stable at different times.

I've requested epel10.2-build-side-123884 and will start building in that shortly.

Still waiting for qt-creator to complete. rocm-validation-suite has apparently gone FTBFS - I've filed https://bugzilla.redhat.com/show_bug.cgi?id=2419068 for that. I guess I could wait a little bit for that, but otherwise I think I would like to submit the update soon.

I have filed https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-b2ba348dbe

I figure the whole point of the compatibility package is for situations like this with rocm-validation-suite, so it will be a good test.

Update seems to be working well. karma for the update would be appreciated.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/epel/steering/issues/359

Please continue any further discussion there.