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