https://bugzilla.redhat.com/show_bug.cgi?id=1251500 --- Comment #4 from Mattias Ellert <mattias.ellert@xxxxxxxxxxxx> --- (In reply to Dominik 'Rathann' Mierzejewski from comment #1) > Is there any particular reason why you set SO version to 0.1? The 0.1 chosen in order to follow https://fedoraproject.org/wiki/Packaging:Guidelines#Downstream_.so_name_versioning (In reply to Rex Dieter from comment #2) > Not sure it's wise to even use shared libs here at all (rather than static > libs)... upstream almost certain makes no ABI guarantees, so any updates > make break stuff without notice. I really don't see the point of insisting on unbundling kwsys if you then rebundle it again by making it a static library. For castxml it is not a big problem - it is a single application so linking against a static library will only bundle one copy of the code into the application which is not worse than the unbundled case - but also not much better. For the other user of kwsys in Fedora that I am aware of - InsightToolkit - the currently bundled copy of the kwsys sources is compiled into a shared library (libitksys). Most of the other libraries in this package - and there are many - link to this library. If this would be unbundled using a common static library from Fedora each of these libraries would get a bundled copy of the static library - which I think would be a worse situation than the currently one bundled shared copy. In my opinion - if the Fedora common version would be a static library I think it would be better to accept kwsys as a copylib. Unbundling only makes sense if the Fedora common version is a shared library. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review