Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=886112 --- Comment #2 from Michael Schwendt <mschwendt@xxxxxxxxx> --- Just some comments (no review of the spec file): I recommend that not much attention is paid to the old review request bug 187294 anymore. Not because that has been several years ago, but because there is *a lot* to read, which goes back and forth for a long time without focusing on *how* all the this stuff will be used by actual users of this software --> as that might be important when deciding where to place files and in which package to put them. That can also be important when deciding whether to split off extensions to reduce installation footprint. The purpose of the packaging guidelines is not to move/delete/rename files until the package software no longer works. ;) Focus on where files must be installed as intended by the software. Then double-check whether the guidelines say anything about file locations or special files. For example, it's possible to mispackage something with a wrong %configure call or because a build framework determines wrong paths. > But there were some issues about plug-ins. There still are. First of all, helpful would be to clear up the naming issues. This adds some of the confusion so far: $ rpmls -p gwyddion-2.30-2.x86_64.rpm|grep modu|wc -l 210 $ rpmls -p gwyddion-2.30-2.x86_64.rpm|grep plug|wc -l 1 $ rpmls -p gwyddion-2.30-2.x86_64.rpm |grep plug -rwxr-xr-x /usr/lib64/gwyddion/modules/plugin-proxy.so There are hundreds of Gwyddion "modules" (extensions). Further ones can be developed with the help of the -devel package and the -devel-doc C API documentation. These modules (shared libraries) result in automatic RPM Provides for the shared libraries: $ rpm -qp --provides gwyddion-2.30-2.x86_64.rpm|grep \.so|wc -l 212 The packaging guidelines try to avoid this (for various reaons, not limited to repository metadata bloat): https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering There is the Gwyddion module "pygwy", which can be used to write Gwyddion modules in Python. It adds a dependency on Python libs, so splitting it out into a subpackage may make sense. This module is duplicated, however, as it's also included in the main package. Easy to Fix. Whether to split it out at all depends on how optional these Python bindings are considered by the developers or the typical user of the software. There are Gwyddion "plugins", which are executable scripts written in programming languages, such as Perl, Python, Ruby. However, the run-time directories /usr/libexec/gwyddion/ /usr/libexec/gwyddion/plugins/ are included in the -devel package. Easy to fix. The separate module packages for programming language support are named "*-plugin-module" even: %description perl-plugin-module Perl module to read Gwyddion dump files used in plug-ins. %description python-plugin-module Python module to read Gwyddion dump files used in plug-ins. %description ruby-plugin-module Ruby module to read Gwyddion dump files used in plug-ins. These aren't Gwyddion modules and neither Gwyddion plug-ins. And they are not stored in the "modules" directory, but, for example, the Perl module is not stored in Perl's search path for modules either. It seems correct to filter out the "Gwyddion::dump" RPM Provides for the Perl module. Provided that this isn't supposed to be a global Perl module instead. Similarly for Python and Ruby. How else would this work? > I would also make them public, if it is better from your point of view. The Perl module even comes with a man page, which gets deleted in the spec file. Primary objective is to package the software correctly. Only afterwards think about possible packaging optimizations, such as a split into run-time, build-time, documentation, optional extensions. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=GcmSd2ZCRF&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review