Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=886112 --- Comment #7 from Michael Schwendt <mschwendt@xxxxxxxxx> --- > much grief More like going in circles, also due to misunderstandings, IMO. In the old review in bug 187294 comment 26 it was said: | not having the modules as regular modules isn't a blocker. A few comments later in bug 187294 comment 31 the review feedback makes your brain go mad, because the added comment is very general and doesn't even cursorily touch the earlier topic about where to store these plug-in support modules. There is not enough context in the nearby comments to tell what exactly the comment tries to address. My general advice with regard to placement of Perl/Python/Ruby modules (as the examples that are in use here) is to pay attention to how these modules are used. Just because something is a "Python module" does not imply that it must be made available in Python's default search path. Perhaps it doesn't even offer a well-defined interface and comes without any guarantees on interface stability. There are applications, which are built out of modules stored in private paths (e.g. below an application's home directory), because the modules are not for public consumption. Same for Perl, ... What's special about Perl is that there are automatic RPM Provides and Requires added to the built packages. For Python and Ruby that doesn't exist yet. Except for the executable scripts causing an automatic dependency on the interpreter: $ rpm -qpR gwyddion-ruby-plugin-module-2.30-2.x86_64.rpm|grep -v ^rpm /usr/bin/ruby gwyddion(x86-64) = 2.30-2 ruby The packager needs to be aware of the various consequences related to packaging Perl modules. If an external Gwyddion plug-in written in Perl were to be packaged, the same issue could turn up again, and it could become necessary to filter the automatic Perl dependency data again. No package would advertize that it includes the perl(Gwyddion::dump) module, and hence no package could depend on that. But that still _doesn't_ imply the module must be moved into global module search path. > not placing them to the standard search paths. The example plug-ins try to make that clear with an error message: "Plug-in has to be called from Gwyddion plugin-proxy." They assume that the support modules are only available in the environment of the plugin-proxy. -- 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=GmZM35Cmme&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review