Bug 886112

*** Bug 187294 has been marked as a duplicate of this bug. ***

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.

$ gwyddion
gwyddion: Symbol `fftw_version' has different size in shared object, consider re-linking

(gwyddion:26454): Module-WARNING **: Cannot add non-existent path '/usr/share/gwyddion/pygwy'.

[...]

That's with a test-build of gwyddion-2.30-2.src.rpm on Fedora 18, with just the main package installed.

The warning about fftw may be unrelated, perhaps due to updates-testing.

The warning about pygwy sort of asks for reconsidering the package-split, or at least, putting the directory entry into the main package.


> make %{?_smp_mflags}

Prepend  V=1  here, please, for verbose output of future package releases. That will make build.log contents much more useful.

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?

> 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

If I knew how much grief the plug-in system would create....

I will try to clarify one point: The plug-in system is ill-conceived but real people use it and depend on it; we care about compatibility and do not break things just because we would do them differently now.  From this two conclusions follow:

(1) If someone puts a perl/python/whatever plug-in script to ~/.gwyddion/plugins it must work as with upstream, otherwise the package is broken.  This can be ensured by different means.

(2) Use of the plug-in support files should not be encouraged, especially not outside gwyddion plug-ins.  I would say this can only be done by not placing them to the standard search paths.

If I embedded the support files into plugin-proxy.c, (re)created them somewhere in user's ~/.gwyddion each time plugin-proxy is loaded and set GWYPLUGINLIB to point there, it would make this issue disappear from the reviewer's radar.  It would fit the purpose but I doubt it would be saner than just dumping them to libdir.

> 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.

(In reply to comment #7)
> If an external Gwyddion plug-in written in Perl were to be packaged...

I promise to rewrite personally the thing to C or pygwy in such case.  Or just package the three simple Perl functions that have not changed for 8+ years with it.  I am much more worried that Fedora will stop shipping gtk2 someday than that someone publishes a Perl Gwyddion plug-in which becomes so popular that a need to package it for Fedora arises.

I'm not worried. I don't suggest putting the stuff into standard search path. ;)

And gtk2? Hey! :) Check this out:

$ yum list gtk+|grep ^g
gtk+.i686                         1:1.2.10-73.fc18                        fedora
gtk+.x86_64                       1:1.2.10-73.fc18                        fedora

# repoquery --whatrequires gtk+|grep -v i686|wc -l
34
# repoquery --whatrequires gtk+|grep -v i686|grep -v xmms|wc -l
16

# repoquery --whatrequires gtk2|grep -v i686|wc -l
1042
# repoquery --whatrequires gtk3|grep -v i686|wc -l
411

(In reply to comment #9)
> gtk+.i686                         1:1.2.10-73.fc18       fedora
> gtk+.x86_64                       1:1.2.10-73.fc18       fedora

That's what I meant.

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-4.src.rpm

I was rather busy, finishing my masterthesis the last 2.5 weeks.
Now I've got more time to deal with this.

I decided to package the plugin support files and examples as one package and remove the Perl Provides.

I'm requesting the status of this package, are you still interested in this?

Well I'm, but it still needs a reviewer or even better co-maintainer.

It is not possible to build in mocked environment (try it in fedora-review tool):

/usr/bin/install: cannot stat 'Gwyddion::dump.3pm': No such file or directory
make[2]: *** [Makefile:583: install-data-local] Error 1
make[2]: Leaving directory '/builddir/build/BUILD/gwyddion-2.30/perl'
make[1]: *** [Makefile:464: install-am] Error 2
make[1]: Leaving directory '/builddir/build/BUILD/gwyddion-2.30/perl'
make: *** [Makefile:531: install-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.yjtbOC (%install)
    Bad exit status from /var/tmp/rpm-tmp.yjtbOC (%install)

Also "rm -rf %{buildroot}" should be removed from %install.

Actually I have no time to care about this any more.

Well, we've been providing Fedora packages ourselves for a dozen of years -- and a repo since 2011.  Unlike some software du jour which goes from ‘everyone should use this’ to ‘deprecated’ in a couple of years, Gwyddion does something valuable to its users.  If someone reopens this in 5 years, you are welcome.  We will be still there, waiting, albeit not expecting much...