https://bugzilla.redhat.com/show_bug.cgi?id=1760617 --- Comment #18 from Qianqian Fang <fangqq@xxxxxxxxx> --- @Ankur your points are taken - I have no objection to the current policy regarding bundling: if a system library already exists and it makes sense to dynamically link to it to avoid duplication, but embedding open-source codes/units in a larger project is also a very common practice and there are even dedicated tools to facilitate such use (such as git submodule, or header-only libraries). I understand your standing point of pushing reusable libraries in the context of building a healthy, modular and dynamic distribution/software environment, but as a software developer and distributor, I also have to pay extensive attention to 1) portability - i.e. to ensure smooth/easy software compilation not only on a specific distribution, but other platforms including Windows/Mac, 2) stability - including both forward and backward compatibility that are independent to external library interface changes, 3) performance - some of the libraries, such as sse_math and SFMT, are primarily used for their "inline" functions that are important for the software performance/speed, unless the library was specifically coded to ensure inlined functions, moving towards dynamic linking will likely result in speed loss. again, your points were loud and clear, but my assessment, as an upstream author and packger, is that the suggestion for decoupling the embedded libraries for separate packages and dynamic link with those will require a lot more work but no clear benefit (or even detrimental in terms of speed) for the software itself. So, I prefer to move forward in the current package/source code settings. Regarding the suggested "Provides: bundled(...)" line, I just want to make sure - this package neither compiles nor installs private copies of separate library files for sse_math/sfmt/json; it only statically compiles/links with them in our mmc/mmc.mex binaries. No one could directly call the functions in these embedded libraries from the generated binaries (mmc/mmc.mex). In this case, is a "Provide" directive still appropriate? -- 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 To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx