Spec URL: https://download.copr.fedorainfracloud.org/results/avigne/librnd/fedora-rawhide-x86_64/02315051-librnd/librnd.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/avigne/librnd/fedora-rawhide-x86_64/02315051-librnd/librnd-3.0.0-1.fc35.src.rpm Description: Modular framework library for 2D CAD applications. Fedora Account System Username: avigne This library is extracted from pcb-rnd, a PCB editor tool. See http://www.repo.hu/projects/ringdove/ web site to get a broader context (EDA suite)
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]. Not sure how real support exist for those libraries in system, the build systems of this package is not something I full understand. 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. -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. -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. 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. genregex is Public Domain, I think it should be also in License: tag. 1. http://repo.hu/projects/ 2. https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling
(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
(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
Still interested in this review? %{nameAPI} is not necessary I think. If incompatible changes appear in the code, dependent package have to adjust. If they do at the same time, there is little benefit of major version being part of every subpackage. If that changes, dependent packages have to adjust all dependencies. It is required on Debian, but not recommended practice on Fedora.
Yes, I am still in ! Now the library is at version 3.1.0, which is my next target for a new .spec file... Meanwhile, I wish to propose a new package : http://repo.hu/projects/fungw/ (new bug/package review to come ASAP) which itself is depending on MuJS (https://src.fedoraproject.org/rpms/mujs), the package I updated today... Thank you for your patience.
I did update the MuJS package + fungw one. Now librnd is at version 3.2.0, and I have a successful COPR : https://download.copr.fedorainfracloud.org/results/avigne/librnd/fedora-rawhide-x86_64/04632036-librnd/ So, I propose again these new package. Thank you for your help. (I will be off till 07/18) Spec URL: https://avigne.fedorapeople.org/librnd.spec SRPM URL: https://avigne.fedorapeople.org/librnd-3.2.0-1.fc36.src.rpm Description: Modular framework library for 2D CAD applications. Fedora Account System Username: avigne
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time, but it seems that the review is still being working out by you. If this is right, please respond to this comment clearing the NEEDINFO flag and try to reach out the submitter to proceed with the review. If you're not interested in reviewing this ticket anymore, please clear the fedora-review flag and reset the assignee, so that a new reviewer can take this ticket. Without any reply, this request will shortly be resetted.
Okay, fedora-review tool seem to be broken on current rawhide. Will have to check it later.
This is an automatic action taken by review-stats script. The ticket reviewer failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we reset the status and the assignee of this ticket.