I'm still trying to figure out the best way to frame the problem and I don't have a specific solution in mind, but there's got to be a better solution for dealing with projects that make major API changes.
Pre-side-tag this was even more difficult:
1. Make sure the new version builds
2. Maybe do some testing with dependencies
3. Update the package and break Rawhide
4. Deal with the fallout
At least with side tags it buys us some time to port over packages that don't build cleanly, but the longer these are open, the more likely other people have touched them creating other issues.
I've actually started creating COPRs for this purpose and that helps check things out "offline" from the main distro, but it's not a 100% solution.
What do we do with packages where SOME but not all of the dependent packages support the new API?
Conservative option: Wait until they do and don't upgrade the package.
This is fine in the short term (3-6 months?) but many upstreams are less than aggressive about updating dependencies and could potentially take a year or more.
Middle of the road (but a lot of work) option:
1. Create a compat or SOVERSION appended package (requires new review)
2. Migrate the packages that won't build to it, build the new package and working deps.
One big caveat is that in some cases it's all or nothing for the whole "stack"
Contrived example:
OpenImageIO can build with OpenColorIO 2.0 but blender can't (has since been fixed).
I can't rebuild OIIO with OCIO 2.0 and leave Blender at OCIO 1.X. Worse, while it's a good thing I know about this dep chain, I'm unaware of any systematic method to detect this so it completely relies on packager knowledge, and we know how problematic that is with all the soname breakages even though the guidelines are quite explicit there.
Aggressive option: Build it anyway and deal with the fallout the best we can.
I don't actually think this is practical but included it for completeness.
OpenEXR 3 (ongoing saga)
vtk 9.0 (pretty much done, but was painful)
Thoughts?
Thanks,
Richard
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
