https://bugzilla.redhat.com/show_bug.cgi?id=1981493
--- Comment #2 from Alain V. <alain.vigne...@gmail.com> --- (In reply to Petr Menšík from comment #1) Hello Petr, and thank you for taking the time to review my proposal > Informal only review. > > The library bundles several projects, which seems to have their own version > and release tarballs at repo.hu [1]. At least for non-trivial parts, I think > it should include entries like: > Provides: bundled(liblihata) > > for all used directories in src_3rd. That would include at minimal libfungw, > liblihata, genvector. Ideally those libraries should have own package, but I > haven't found any trace requiring them. Because they have own versions and > repos, they should be mentioned as bundled libraries [2]. There are 16 "sub projects", and I am working with upstream on how to "unbundle" those. Some will never be unbundled, because they are meant to be included in source tree as is. Situation has to be improved (other package reviews to come ;), but meanwhile, this is what it is... Next .spec proposal will explore usage of external libgenht https://src.fedoraproject.org/rpms/libgenht > Not sure how real > support exist for those libraries in system, the build systems of this > package is not something I full understand. > The build system is not automake nor meson. It is homegrown C/script/make build system. It complicates the situation w.r.t bundled/external libraries, but just should work... > What is main benefit of using %{nameAPI} instead of just %{name}? I think at > least %{nameAPI} package should include: > Provides: %{name} = %{version}-%{release} > > Does it expect installation of multiple versions on the same system? Is > there reason for such approach? I know Debian packages use version of > library always in the package name, but it is not common in Fedora. I think > it is only used where multiple different versions have to be supported. > It is expected a librnd4 major API would be // installable with current librnd3 one. Well, I don't see an usage for %{name} only. You do want to "map" %{name} to a given %{nameAPI} like for ex. python=python3 ? > -doc subpackage does not require main package, but does not have own copy of > %license. Either require main package or include separate copy. License has > to be installed always with any content from package. Even documentation. > I agree I have to provide a license for -doc. I don't want to depend on main package. > -static subpackage is not needed and should not be provided. Any code using > this library should link to shared libraries, never static. At least > anything packaged. Just rm lib*.a instead of separate package. > Upstream insists on presence of .a lib, generates and installs the file I tried my best to content upstream and https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries > Please remove index.html suffix from URL. It looks better without it and > works. Source0 can be %{url}/releases/%{name}-%{version}.tar.gz, since the > beginning is the same. > OK, will do > genregex is Public Domain, I think it should be also in License: tag. > OK, will do I will publish a modified .spec, as soon as I can, but with minor changes. Do you think the package can be approved, or we need to wait for other packages to unbundle what it could ? I am in favor of accepting the package as it is, and work with upstream to slowly change situation in the future (with newer releases as well). Thanks again. > 1. http://repo.hu/projects/ > 2. 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@lists.fedoraproject.org To unsubscribe send an email to package-review-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/package-review@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
