<top post>
Or, if I may be so bold—
Convince the developers to use versioned symbols when they break the API/ABI.
This is the 21st Century, and we have solutions for this. It's not rocket surgery.
</top post>
On Thu, Jul 1, 2021 at 11:55 AM Richard Shaw <hobbes1069@xxxxxxxxx> wrote:
_______________________________________________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 builds2. Maybe do some testing with dependencies3. Update the package and break Rawhide4. Deal with the falloutAt 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.Other recent examples: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
_______________________________________________ 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
