https://bugzilla.redhat.com/show_bug.cgi?id=1981493 --- Comment #3 from Petr Menšík <pemensik@xxxxxxxxxx> --- (In reply to Alain V. from comment #2) > (In reply to Petr Menšík from comment #1) > Hello Petr, and thank you for taking the time to review my proposal > 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 Oh, haven't tried every library. If already some libraries exist packaged in Fedora and they are compatible, they MUST be used instead of another copy. It would be great if upstream would be able to help with that. I think it is okay not to package everything as separate package if we are almost sure no other package uses them. But they should be marked as bundled provides. I have checked versioning system, it seems they were quite reduced [1]. Anyway, just defining provides is better than nothing. Allows using dnf repoquery --whatprovides 'bundled(libulzw)' to check what packages make take advantage from separate package. If it returns just single or no package, there is little benefit from separate package. I would generate provides just simple way: (cd src_3rd && for D in *; do [ -d "$D" ] && echo "Provides: bundled($D)"; done) I expect only sources from repo.hu are likely to be able to reuse some code from it. I guess we can spend few lines on it. You are maintainer of libgenht anyway. I would expect you should be the best qualified to know what possible librnd dependencies might be able to reuse some of those src_3rd libraries. If they all use just librnd, there is no point packaging each tiny library separately. > 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... It definitely complicates replacing bundled static library with system library. If upstream author is will help, it would be great. Common build systems like autotools, cmake or meson have already some best practice to reuse. There seems to be some support for separate libraries, just not sure what way would be the best. > 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 ? Well, python very different example. It is common to have only one version of the package in the distribution. If it is possible, only the last version is preferred. Problem is different major version usually means different upstream sources. When different upstream sources are used, usually also spec file and base repository is different. That means python3 and python2 were different packages. I would leave main librnd package without version just for latest release available. If older version were required by some dependencies when some other required more recent version, new Review would be required for %{name} == librnd3. That means RPM spec file would be named librnd3.spec. Then %package doc from librnd3.spec would create librnd3-doc package. If you just copy that spec to librnd4.spec and update Version: to 4.x, it would produce librnd4-doc. It seems the %{nameAPI} just makes more difficult. Another version would require another review and spec, different versions should not be mixed inside single source package. That is why I think %package -n %{nameAPI}-something should be just %package something. It is shorter, more readable. And actually simpler to make another major version. I don't think codebase linking to librnd can be compared to amount of useful python code ready to be packaged. I could be wrong. I would start just with single version and think about multiple versions only when we have multiple applications using this package. We do not have and other review blocking this one (yet). > 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 That is not uncommon, some package always generate .a libs no matter what parameters are used. We just don't package them, often they are removed after %make_install: rm -f %{buildroot}%{_libdir}/lib*.a > > > 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. > I am not sure we need to unbundle everything. I have no idea what software can use this library. If more packages from repo.hu should be packaged and every package contained copy of libfungwbind for example, some effort to make it shared library should be spent. I understand packaging all those libraries separate way would be a lot of work. So we should only mark this package as using them in case someone packages some of those libraries later. I would make an exception with libgenht since you have already made that a shared library. Since this is library itself, do you know which packages would use it in the future? Is there software you would like to use it? 1. http://cgi.repo.hu/cgi-bin/minisvn.cgi?cmd=browse&repo=librnd&path=/trunk/src_3rd -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
