[Bug 886112] Review Request: gwyddion - SPM analysis tool in gtk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=886112

--- Comment #5 from Michael Schwendt <mschwendt@xxxxxxxxx> ---
> Now about the plugin-module packages:
> 
> In the original software distribution, those are installed in
> /usr/lib/gwyddion/{perl,python,ruby}. 

Here the test-build on x86_64 installed them into %_libdir, i.e.
/usr/lib64/gwyddion/{perl,python,ruby}, whereas it is /usr/lib for other
architectures. /usr/lib would be suitable on x86_64 (and other lib64
platforms), too, but only for arch-independent files. So, the varying path made
me curious:

You've acknowledged that in order to be able to use these modules, the plug-in
developers need to extend the system's default search path for modules. In
every plug-in.

What do the example plug-ins do? They evaluate a GWYPLUGINLIB environment
variable. Reading the documentation, this env var is exported by the
plugin-proxy module.

Conclusively, one cannot simply move those language modules to somewhere else.
They MUST be packaged in the path that matches the plugin-proxy module. As
intended, matching upstream.

File modules/plugin-proxy.c derives the value for GWYPLUGINLIB from its
"modules" directory path, with the help of libgwyddion/gwyutils.c, which
chooses between built-in paths and overridden ones. The file mentions the base
"gwyddion" man page, which refers to /usr/local in a few places, however.


This is an area, where the package submitter/maintainer should have the final
say on where to install files, since it will be the packager who will need to
deal with bug reports and complaints, if the software doesn't work because it's
mispackaged. ;-) A reviewer should give a compelling reason why to move files.
We don't move files just for fun.

But, for example, you could move the Perl Gwyddion::dump man page into the %doc
area, so it isn't lost.


> This and the added dependency for the interpreters lead to discussion
> in the former request.

Which is surprising. _If_ Perl is considered optional, you could split out all
Perl stuff into a gwyddion-perl package. And e.g. all Python stuff into a
gwyddion-python or the existing gwyddion-pygwy package (a cryptic name, btw).
Would it be important that somebody could run Gwyddion with plugins written in
Python, but without installing pygwy for Gwyddion modules written in Python?

There is no guideline that mandates how much to split out into optional
subpackages. This is up to the package maintainer again. It would even be okay
to include Perl, Python and Ruby stuff in the base package, but it could be
that the package users will complain about the "dependency bloat". ;)


> Maybe one could even make them following normal naming guidelines for
> extensions and name them perl-gwyddion-dump etc.

That would be misleading for Perl modules outside module search path, IMO.
Sure, you could ask packaging list, but I'd like to suggest whoever answers has
read this ticket first.


> Last about the auto-provides:
> 
> In https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering 
> it says:

You could use RPM's internal dependency generator, which has been improved
since RPM 4.9. See bottom of:

http://rpm.org/wiki/PackagerDocs/DependencyGenerator

-- 
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=x4Kr8H8q8N&a=cc_unsubscribe
_______________________________________________
package-review mailing list
package-review@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/package-review



[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]