[Bug 2052939] New: Review Request: libfungw - C library for dynamic function calls in different languages
https://bugzilla.redhat.com/show_bug.cgi?id=2052939
Bug ID: 2052939 Summary: Review Request: libfungw - C library for dynamic function calls in different languages 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/libfungw/fedora-ra... SRPM URL: https://download.copr.fedorainfracloud.org/results/avigne/libfungw/fedora-ra... Description: Fungw is a tiny, portable library written in C (C89) that manages dynamic function calls across different programming languages. Fedora Account System Username: avigne
Successful builds: https://copr.fedorainfracloud.org/coprs/avigne/libfungw/build/3427366/
https://bugzilla.redhat.com/show_bug.cgi?id=2052939
Alain V. alain.vigne.14@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Doc Type|--- |If docs needed, set a value
--- Comment #1 from Alain V. alain.vigne.14@gmail.com --- rpmlint: libfungw.spec:214: W: configure-without-libdir-spec There is a comment in the .spec file. I consider this warning as OK.
fedora-review: - Development (unversioned) .so files in -devel subpackage, if present. Note: Unversioned so-files directly in %_libdir.
The .so files in %_libdir are opened inside the application (not via the linker) using dlopen(). Upstream decided to store the files there, why not.
But the main libfungw: /usr/lib64/libfungw.so is unversioned, and should be. This is already reported to upstream and might be corrected for next fungw version.
https://bugzilla.redhat.com/show_bug.cgi?id=2052939
Petr Menšík pemensik@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pemensik@redhat.com
--- Comment #2 from Petr Menšík pemensik@redhat.com --- Why is this package called libfungw, when upstream repository and page refers to it only as fungw? Does that conflict with existing fedora package? I think fungw is better name for the package.
Why do you have %{name}-perl aliases and then use
%package -n %{libperl} ??
%package perl without -n produces just %{name}-perl by default. It is simpler, cleaner and easier to read. Unless different prefix is required, use just suffixes for subpackages. There are multiple definitions not really required.
Just use:
%package perl Requires: %{name}...
%description perl Blabla
%files perl %{_bindir}/whatever
It the application uses dlopen, I think it should have own subdirectory %{_libdir}/%{name}, where it would store its own shared code/libraries. %_libdir is reserved for libraries used by ld.so.
https://bugzilla.redhat.com/show_bug.cgi?id=2052939
--- Comment #3 from Alain V. alain.vigne.14@gmail.com --- (In reply to Petr Menšík from comment #2) Hi Petr, thank you for your interest in this lib, which is a follow-up work of our previous thoughts on librnd...
Why is this package called libfungw, when upstream repository and page refers to it only as fungw? Does that conflict with existing fedora package?
The 2 names are present in this proposal. There is a meta package called fungw (the %{srcname}) and libfungw. I know this complicates the .spec file, but it is a "request" from upstream dev. http://www.repo.hu/projects/fungw/packaging.txt See also the Debian page https://packages.debian.org/sid/libs/fungw
I think fungw is better name for the package.
Why do you have %{name}-perl aliases and then use
%package -n %{libperl} ??
%package perl without -n produces just %{name}-perl by default. It is simpler, cleaner and easier to read. Unless different prefix is required, use just suffixes for subpackages. There are multiple definitions not really required.
Just use:
%package perl Requires: %{name}...
%description perl Blabla
%files perl %{_bindir}/whatever
I tend to agree with you... If I can manage to implement this, I'll keep your proposal.
It the application uses dlopen, I think it should have own subdirectory %{_libdir}/%{name}, where it would store its own shared code/libraries. %_libdir is reserved for libraries used by ld.so.
You are correct. I need to add this line.
I'll update this ticket with new .spec + SRPM as soon as I can. Regards
https://bugzilla.redhat.com/show_bug.cgi?id=2052939
--- Comment #4 from Alain V. alain.vigne.14@gmail.com --- Updated proposal Spec URL: https://avigne.fedorapeople.org/libfungw.spec SRPM URL: https://avigne.fedorapeople.org/libfungw-1.2.0-2.fc35.src.rpm
COPR https://copr.fedorainfracloud.org/coprs/avigne/libfungw/build/3503216/
https://bugzilla.redhat.com/show_bug.cgi?id=2052939
--- Comment #5 from Petr Menšík pemensik@redhat.com --- Interesting request of upstream author. I am not sure he meant that exact naming. I think he is influenced heavily by debian ways. I think the source package should still be called just fungw, just as is original source archive.
I would make fungw-libs package to contain basic shared library. Then fungw binary package would become that metapackage, where fungw-libs would replace libfungw as requested by the author. It is not always prefixed with lib on fedora. I think author was talking more about package suffixes. His expectation matches how it is done on Debian. While we can use the same package names, I think that might not be necessary, because it does not match common practice on Fedora. And makes packaging extra complicated. Maybe you could ask author, whether libfungw prefix for binary package is required also on distributions, where lib prefix is not usually used for binary packages.
I think the difference can be easily demonstrated on json-c packages: Debian: https://packages.debian.org/source/sid/json-c Fedora: https://koji.fedoraproject.org/koji/buildinfo?buildID=1886942
Some packages require specific prefix. For example python3 modules have to be named python3-something. This package has python3 subpackage, but I am not sure how it should be used. If it would be used by import fungw, the package name would have to be python3-fungw.
It seems to me all those subpackages would cause multilib conflicts between i686 version and x86_64. libfungw-c.i386 and libfungw-c.x86_64 cannot be installed on the same machine. That is required for libraries. Is that puplug part required? Is it even used somewhere? Because it conflicts, it seems it should have be in separate subpackage, which would conflict with itself.
Is there some example, how should this package be used from shell, lua or perl? It has many languages support, but I am uncertain how it should be used. It has python support, but I don't even know how to start with that.
I think devel subpackage should not contain link /usr/lib64/libfungw.so.1, but just symlink /usr/lib64/libfungw.so -> libfungw.so.1. Which would link -lfungw to current version. It seems wrong way now. libfungw contains libfungw.so, but libfungw-devel contains just %{_libdir}/%{libname}.so.%{major}. devel should contain %{libname}.so, package with library should contain %{libname}.so.%{major}.
This all seems quite complicated stuff. I think documentation and examples should have own BuildArch: noarch subpackage. I barely understand those examples, I think they would be very useful. But whole examples content should be marked as %doc. It should not be bundled in binary libraries. Either move it to devel or create doc subpackage.
https://bugzilla.redhat.com/show_bug.cgi?id=2052939
--- Comment #6 from Alain V. alain.vigne.14@gmail.com --- (In reply to Petr Menšík from comment #5)
Interesting request of upstream author. I am not sure he meant that exact naming. I think he is influenced heavily by debian ways. I think the source package should still be called just fungw, just as is original source archive.
That was my first idea too, but the Debian way enters the dance. The author is using Debian related distro and insists a LOT on using "project" standard package names: - for the user to see kinda "similar" packages and packages name in different distros - for the developer : ease the support if "standardized" - scripting : in doc/auto , some info related to packaging could be used in an automatic script : derive .spec file from those info... Other packagers do that (for Mageia for ex.). I don't.
I would make fungw-libs package to contain basic shared library. Then fungw binary package would become that metapackage, where fungw-libs would replace libfungw as requested by the author. It is not always prefixed with lib on fedora. I think author was talking more about package suffixes. His expectation matches how it is done on Debian. While we can use the same package names, I think that might not be necessary, because it does not match common practice on Fedora. And makes packaging extra complicated.
I did follow the developer's request. Now, I don't want to completely rewrite the .spec file with the alternate choice.
Maybe you could ask author, whether libfungw prefix for binary package is required also on distributions, where lib prefix is not usually used for binary packages.
"Package names don't matter runtime, no code depends on package names in fungw or anything that uses fungw. So packagers are free to name packages whatever they like..." is the author's answer.
I think the difference can be easily demonstrated on json-c packages: Debian: https://packages.debian.org/source/sid/json-c Fedora: https://koji.fedoraproject.org/koji/buildinfo?buildID=1886942
Some packages require specific prefix. For example python3 modules have to be named python3-something. This package has python3 subpackage, but I am not sure how it should be used. If it would be used by import fungw, the package name would have to be python3-fungw.
The use case I know of is: calling a Python script from a C program. This is all about a C library being able to execute scripts in foreign language... So, no this is not a python3-something .
It seems to me all those subpackages would cause multilib conflicts between i686 version and x86_64. libfungw-c.i386 and libfungw-c.x86_64 cannot be installed on the same machine. That is required for libraries. Is that puplug part required? Is it even used somewhere? Because it conflicts, it seems it should have be in separate subpackage, which would conflict with itself.
My understanding is : the puplug is upstream developed plugin system, using some files like /usr/lib/puplug/fungw_fawk.so with a .so extension (like it or not). They are very much needed ! About dynamic libs, depending on arch, you would find (as an example) /usr/lib64/libfungw_fawk.so.1 (x86_64) or /usr/lib/libfungw_fawk.so.1 (i386) So, no. I think there is no collision, and everything is fine.
Is there some example, how should this package be used from shell, lua or perl? It has many languages support, but I am uncertain how it should be used. It has python support, but I don't even know how to start with that.
You don't start with a Python console, or shell or... : you write C code first.
I think devel subpackage should not contain link /usr/lib64/libfungw.so.1, but just symlink /usr/lib64/libfungw.so -> libfungw.so.1. Which would link -lfungw to current version. It seems wrong way now. libfungw contains libfungw.so, but libfungw-devel contains just %{_libdir}/%{libname}.so.%{major}. devel should contain %{libname}.so, package with library should contain %{libname}.so.%{major}.
ACK. corrected in next .spec version.
This all seems quite complicated stuff. I think documentation and examples should have own BuildArch: noarch subpackage.
ACK. corrected in next .spec version.
I barely understand those
examples, I think they would be very useful. But whole examples content should be marked as %doc. It should not be bundled in binary libraries. Either move it to devel or create doc subpackage.
doc subpackage ...
https://bugzilla.redhat.com/show_bug.cgi?id=2052939
--- Comment #7 from Alain V. alain.vigne.14@gmail.com --- Spec URL: https://avigne.fedorapeople.org/libfungw.spec SRPM URL: https://avigne.fedorapeople.org/libfungw-1.2.1-1.fc35.src.rpm Description: Fungw is a tiny, portable library written in C (C89) that manages dynamic function calls across different programming languages. Fedora Account System Username: avigne
Successful builds: https://copr.fedorainfracloud.org/coprs/avigne/libfungw/build/4365206/
https://bugzilla.redhat.com/show_bug.cgi?id=2052939
Alain V. alain.vigne.14@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1981493
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1981493 [Bug 1981493] Review Request: librnd - library for 2D CAD applications
https://bugzilla.redhat.com/show_bug.cgi?id=2052939
Benson Muite benson_muite@emailplus.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |fedora-review? Assignee|nobody@fedoraproject.org |benson_muite@emailplus.org CC| |benson_muite@emailplus.org Status|NEW |ASSIGNED
Product: Fedora Version: rawhide Component: Package Review
Alain V. alain.vigne.14@gmail.com has canceled Package Review package-review@lists.fedoraproject.org's request for Alain V. alain.vigne.14@gmail.com's needinfo: Bug 2052939: Review Request: libfungw - C library for dynamic function calls in different languages https://bugzilla.redhat.com/show_bug.cgi?id=2052939
--- Comment #9 from Alain V. alain.vigne.14@gmail.com --- I am still interested. I will update the build for latest 1.2.1 version. Soon Alain
https://bugzilla.redhat.com/show_bug.cgi?id=2052939
Alain V. alain.vigne.14@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(alain.vigne.14@gm | |ail.com) |
--- Comment #9 from Alain V. alain.vigne.14@gmail.com --- I am still interested. I will update the build for latest 1.2.1 version. Soon Alain
https://bugzilla.redhat.com/show_bug.cgi?id=2052939
Benson Muite benson_muite@emailplus.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(benson_muite@emai | |lplus.org) |
--- Comment #11 from Benson Muite benson_muite@emailplus.org --- Ok, look forward to reviewing
Product: Fedora Version: rawhide Component: Package Review
Benson Muite benson_muite@emailplus.org has canceled Package Review package-review@lists.fedoraproject.org's request for Benson Muite benson_muite@emailplus.org's needinfo: Bug 2052939: Review Request: libfungw - C library for dynamic function calls in different languages https://bugzilla.redhat.com/show_bug.cgi?id=2052939
--- Comment #11 from Benson Muite benson_muite@emailplus.org --- Ok, look forward to reviewing
package-review@lists.fedoraproject.org
-
bugzilla＠redhat.com