https://bugzilla.redhat.com/show_bug.cgi?id=2129303 --- Comment #3 from Sergey <sergey@xxxxxxxxxxxx> --- (In reply to Benson Muite from comment #2) > Comments: > a) Maybe worth explicitly listing Openssl as a dependency > c) Should MariaDB/LevelDB be added as dependencies for the extra features? As I mentioned earlier, I did not find another OSS project that uses cbang, thoug I was not digging too deep. The sqlite dependency is not needed for camotics, but without it cbang's build fails and there is no option to completely disable it. The openssl is not used by camotics as well. My intent was to make it have as many dependencies as necessary to build camotics. > b) BSD License is for test-harness which seems to not be installed, but is > used in build Does this mean that BSD license must be also listed in `License:`? > d) Should libbfd, libiberty be added as dependencies for debug builds? Yes, this could be useful in problems troubleshooting as the camotics is in pre-release stage and I used to report a bug causing core dump upstream. I'll add these > e) Maybe worth asking upstream to soname the library? I have asked Joseph on his versioning policy in general and he replied that he has no one [0]. As 1) Joseph adds the functionality on as needed basis, 2) there are obvious bugfixes, 3) camotics builds properly with up-to-date version of cbang and 4) cbang exports c++ classes, I decided to use `version.subversion` as an so version, leaving `.revision` for bug fixes in cbang. The leading zero in `libcbang0` is from upstream, I suspect that it is somehow related to debian packaging/naming, so I leaved this as is. However, I will ask Joseph again about soname specifically. > f) Build on ELN fails > https://copr.fedorainfracloud.org/coprs/fed500/cbang/build/4945964/ though > this is not essential Yes, there is no python3-scons at least. > g) For documentation, maybe upstream would consider doxygen, > https://www.doxygen.nl/manual/starting.html#man_out which can generate man > pages? This might avoid some of the duplication in the README and in the > documentation in docs/www? I will see if I can manage with that as Joseph hardly would make docs suite which is not a blocking factor for his development goals. > h) Maybe also remove the scripts folder? done > i) The utilities in general are useful. Can many of them be made available > as subpackages? For example, renewing ACME certificates maybe helpful as a > standalone feature. Subpackages would give greater visibility and encourage > greater use. This is not essential though. Yes, I agree on adoption possibility, but these are mostly use examples. The acmev2 utility would impose OpenSSL dependency. I will update and upload new versions of spec e.t.c. as you respond in regard of BSD License [0] https://github.com/CauldronDevelopmentLLC/cbang/issues/98 -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2129303 _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
