Bug 2052939

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.

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.

(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

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/

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.

(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 ...

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/

This is an automatic check from review-stats script.

This review request ticket hasn't been updated for some time. We're sorry
it is taking so long. If you're still interested in packaging this software
into Fedora repositories, please respond to this comment clearing the
NEEDINFO flag.

You may want to update the specfile and the src.rpm to the latest version
available and to propose a review swap on Fedora devel mailing list to increase
chances to have your package reviewed. If this is your first package and you
need a sponsor, you may want to post some informal reviews. Read more at
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group.

Without any reply, this request will shortly be considered abandoned
and will be closed.
Thank you for your patience.

I am still interested. I will update the build for latest 1.2.1 version.
Soon
Alain