https://bugzilla.redhat.com/show_bug.cgi?id=1981493
Bug ID: 1981493 Summary: Review Request: librnd - library for 2D CAD applications Product: Fedora Version: rawhide Hardware: All OS: Linux Status: NEW Component: Package Review Severity: medium Priority: medium Assignee: nobody@fedoraproject.org Reporter: alain.vigne.14@gmail.com QA Contact: extras-qa@fedoraproject.org CC: package-review@lists.fedoraproject.org Target Milestone: --- Classification: Fedora
Spec URL: https://download.copr.fedorainfracloud.org/results/avigne/librnd/fedora-rawh... SRPM URL: https://download.copr.fedorainfracloud.org/results/avigne/librnd/fedora-rawh... 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)
https://bugzilla.redhat.com/show_bug.cgi?id=1981493
Alain V. alain.vigne.14@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Comment|0 |updated
--- Comment #0 has been edited ---
Spec URL: https://download.copr.fedorainfracloud.org/results/avigne/librnd/fedora-rawh... SRPM URL: https://download.copr.fedorainfracloud.org/results/avigne/librnd/fedora-rawh... 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)
https://bugzilla.redhat.com/show_bug.cgi?id=1981493
Alain V. alain.vigne.14@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Doc Type|--- |If docs needed, set a value
https://bugzilla.redhat.com/show_bug.cgi?id=1981493
Petr Menšík pemensik@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pemensik@redhat.com
--- Comment #1 from Petr Menšík pemensik@redhat.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1981493
--- Comment #2 from Alain V. alain.vigne.14@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-...
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1981493
--- Comment #3 from Petr Menšík pemensik@redhat.com --- (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=/...
https://bugzilla.redhat.com/show_bug.cgi?id=1981493
Petr Menšík pemensik@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Flags| |fedora-review? Assignee|nobody@fedoraproject.org |pemensik@redhat.com
--- Comment #4 from Petr Menšík pemensik@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1981493
--- Comment #5 from Alain V. alain.vigne.14@gmail.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1981493
--- Comment #6 from Alain V. alain.vigne.14@gmail.com --- 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-rawh...
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
https://bugzilla.redhat.com/show_bug.cgi?id=1981493
Alain V. alain.vigne.14@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends On| |2052939
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=2052939 [Bug 2052939] Review Request: libfungw - C library for dynamic function calls in different languages
Product: Fedora Version: rawhide Component: Package Review
Petr Menšík pemensik@redhat.com has canceled Package Review package-review@lists.fedoraproject.org's request for Petr Menšík pemensik@redhat.com's needinfo: Bug 1981493: Review Request: librnd - library for 2D CAD applications https://bugzilla.redhat.com/show_bug.cgi?id=1981493
--- Comment #8 from Petr Menšík pemensik@redhat.com --- Okay, fedora-review tool seem to be broken on current rawhide. Will have to check it later.
https://bugzilla.redhat.com/show_bug.cgi?id=1981493
Petr Menšík pemensik@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(pemensik@redhat.c | |om) |
--- Comment #8 from Petr Menšík pemensik@redhat.com --- Okay, fedora-review tool seem to be broken on current rawhide. Will have to check it later.
https://bugzilla.redhat.com/show_bug.cgi?id=1981493
Benson Muite benson_muite@emailplus.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |DUPLICATE CC| |benson_muite@emailplus.org Last Closed| |2025-06-09 04:30:28
--- Comment #11 from Benson Muite benson_muite@emailplus.org --- If still of interest, review of https://bugzilla.redhat.com/show_bug.cgi?id=2353363 and its dependencies would be helpful.
*** This bug has been marked as a duplicate of bug 2353363 ***
https://bugzilla.redhat.com/show_bug.cgi?id=1981493
Benson Muite benson_muite@emailplus.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends On| |2353410
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=2353410 [Bug 2353410] Review Request: libfungw - C library for dynamic function calls in different languages
https://bugzilla.redhat.com/show_bug.cgi?id=1981493 Bug 1981493 depends on bug 2052939, which changed state.
Bug 2052939 Summary: Review Request: libfungw - C library for dynamic function calls in different languages https://bugzilla.redhat.com/show_bug.cgi?id=2052939
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution|--- |DUPLICATE
package-review@lists.fedoraproject.org
-
bugzilla＠redhat.com