Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=886112 --- Comment #4 from lennart.fricke@xxxxxxxxxxxx --- Spec URL: https://raw.github.com/lennart0901/gwyddion-fedpack/master/gwyddion.spec SRPM URL: https://raw.github.com/lennart0901/gwyddion-fedpack/master/gwyddion-2.30-3.src.rpm About naming: As you already pointed out there are the gwyddion modules that extend gwyddions functionality. Almost all processing functionality in those modules As gwyddion in licensed under GPL another way to extend gwyddion are so called plug-ins. These are external binaries, that are called by gwyddion, when you choose to execute the plugin in the main menu. These plug-ins are considered depreciated by upstream maintainer yeti To aid development of plug-ins in perl, python and ruby. Some perl-,python-,ruby- extension/modules (not to be confused with gwyddion-modules) exists. Now about the plugin-module packages: In the original software distribution, those are installed in /usr/lib/gwyddion/{perl,python,ruby}. This and the added dependency for the interpreters lead to discussion in the former request. I think that it is perfectly ok to put these into the corresponding search path. But it would be different from upstream. It would not break the existing plugins as the search path has to be augmented by the developer of a plugin to contain /usr/lib/gwyddion/{perl,python,ruby}. I have only little clue how to name the plugin-module packages. But last time not splitting out those, lead to discussion. So I decided to split them out. Maybe one could even make them following normal naming guidelines for extensions and name them perl-gwyddion-dump etc. Should I ask about it on the packaging list? I fixed what you commented. And the Warning you mentioned in Comment 2 is there because no package split actually happened as the pygwy.so module was included in the main package. No warnings on startup on i686 now. Last about the auto-provides: In https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering it says: "These filtering macros MUST only be used with packages which meet one of the following criteria: ... Architecture specific packages with no binaries in $PATH (e.g. /bin, /usr/bin, /sbin, /sbin) or libexecdir and no system libs in libdir. This includes all of the subpackages generated from the spec file." This is not the case, unfortunately. Can I do anything about it? -- 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=VyxAHoK8Ih&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review