<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 <hobbes1...@gmail.com> 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 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. > > Other recent examples: > OpenEXR 3 (ongoing saga) > vtk 9.0 (pretty much done, but was painful) > > Thoughts? > > Thanks, > Richard > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
