https://bugzilla.redhat.com/show_bug.cgi?id=1760617 --- Comment #17 from Ankur Sinha (FranciscoD) <sanjay.ankur@xxxxxxxxx> --- (In reply to Qianqian Fang from comment #16) > to add another clarification - mmc uses these libraries internally for file > IO of specific inputs and computations purposes, and has no public interface > to call these libraries externally and allow to use them individually. You > can treat them as private/internal functions (compiled in a single > GPL-licensed binary), not a way to encapsulate/ship the libraries per se to > allow reuse - from this perspective, I felt that calling it "bundling" is > not exactly accurate. Replying to this first. No, bundling simply refers to "not using system versions of libraries". How you use them, or whether or not they are made available by your package is not a factor here. The point is simply that you are using a private version of these libraries. The guidelines should clarify this: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling Now on to the second part: (In reply to Qianqian Fang from comment #15) > @Ankur > > I agree with you that it makes software more modular and scalable if all > dependencies can be built as separate packages. However, I think the > scenario here is slightly different. No, again---this is not why bundling is avoided. Avoiding bundling simply results in software being more modular. The main issue we are trying to avoid is explained better with the help of an example, mmc here: - mmc is bundling SFMT - The current release of SFMT is 5.1 from 2017 Now, since mmc is bundling this SFMT version, as SFMT moves forward with bugfixes/optimisations/enhancements, mmc does not receive any of these. In fact, since we don't know the version of SFMT in use in mmc (I can't find any version information in the code somehow), we cannot say for sure if the SFMT developers are still supporting it. So, if a user finds a bug in the bundled version of SFMT, who then looks into it? If mmc modifies SFMT, then you have effectively forked an older version of SFMT and now responsible for maintaining it---separate from SFMT upstream. > > the 4 external components that mmc depends on, namely, sse_math, waitmex, > cjson and SFMT, are extremely lightweight units, and are designed primarily > for embedded use. For example > > - sse_math is a header-only single-unit header file > - waitmex and cJSON are both single-unit (waitmex.c/.h, cJSON.c/.h) libraries > - SFMT is also a single unit (SFMT.c with multiple header files) library > > if you search on github, the majority of the appearance of SFMT are for > embedded use, similar to mmc, > > https://github.com/search?q=SFMT.h&type=Code That does not make it the right practice from a software development point of view---and the point of the review process is to ensure that we follow software development best practices while adding software to Fedora. (A goal of the NeuroFedora group is also to try and push these software development standards upstream to academics who write software but may not necessarily be trained in software development.) > > same for cJSON > > https://github.com/search?q=cjson&type=Code > > in fact, the embedded use of these utilities are seen as an advantage by the > authors of these tools, and they intentionally designed the unit as portable > and lightweight as possible to enable such use, and also to ensure such by > using a more permissive license (BSD, MIT, ZLIB). If that's the case, then these developers are also not following suggested software development best practices. It is unfortunate. Embedding libraries has more disadvantages than advantages. > > In a way, I am permitted, by the respective licenses, to convert each of the > cited units into GPL and place a uniform license disclaimers in each of the > units, so that it looks more like an integrated/single-licensed source-code > tree, but I prefer not to do that because I have to make such edits again if > I want to sync some of the units to new releases. I also thought it would > give upstream authors more visibility by keeping their original disclaimers > in the source codes; but I did not expect this visibility to turn into a > restriction for me to distribute the final software in the license that I > desire (which is known to be compliant with the upstream licenses). The licensing is fine. > > > again, I am not against packaging these lightweight libraries separately (I > am happy to help), but it is not as beneficial in the case of mmc. Because > these libraries are generally not available even in open-source > distributions, not mention about windows/mac where the majority of mmc users > use, to make mmc dependent to such libraries makes the code hard to compile > for a large portion of my existing users. I will also have to deal with > future changes of the API interfaces and data structures that may happen > independent to my codes. But isn't this a good thing? As the developer, don't you want to use the latest versions of these libraries? What is the advantage of limiting your tool to older versions, (apart from it being convenient)? If the concern is that SFMT etc are not available on most installations, and bundling helps here, can we at least: - version the bundled libraries so we know what snapshot of these in time we're depending on, and - maybe try to always bundle the latest versions? > So, even we can create separate packages for these > utilities, I still prefer my code to embed these lightweight units for > portability This is fine if you want to distribute pre-built binaries directly from Github, but isn't quite relevant when it comes to packaging for distributions. The common way upstreams go about it is by providing an easy compilation option where one can choose between the bundled version of the library or a system version. > - perhaps in the future if these libraries become widely > available like libz, libblas or libOpenCL, then, I may consider switching to > dynamic linking mode. This is a catch-22. If everyone keeps bundling them, there will be no incentive to make them available in distributions XD > let me know if this makes sense to you. Sure, I understand where you are coming from. As I've said, bundling is not forbidden anymore---it used to be. It is up to you as developer + package maintainer to decide if bundling is the way to go. At the same time, though, it is our role as reviewers to have this discussion to see if bundling can be avoided. If we're going ahead with bundling, please follow the guidelines and include the required Provides: .. statements in the spec.: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling -- 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
