https://bugzilla.redhat.com/show_bug.cgi?id=2052939 --- Comment #6 from Alain V. <alain.vigne.14@xxxxxxxxx> --- (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 ... -- 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 https://bugzilla.redhat.com/show_bug.cgi?id=2052939 _______________________________________________ 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
