Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: gwyddion https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187294 ------- Additional Comments From yeti@xxxxxxxxxxxxxxx 2006-09-07 16:42 EST ------- (In reply to comment #13) Part II: Unclear stuff. > There is a missing Requires on ruby and python in -devel (I would > have guessed that they were autodetected, but that's not > the case???). > However, the plugins should certainly be in a separate subpackage, > called maybe gwyddion-plugin-examples, together with all the > internal ruby/perl/python modules. Another benefit of doing > a subpackage is that this subpackage could have only > code in the public domain (as it seems to me, but I haven't checked > everything) and could have a a licence marked as such. The most clean solution from the packaging point of view perhaps would be to split the plug-in stuff by language and require individual interpreters in the subpackages. In fact, since there are two kinds of ruby plug-ins, there should be a plain ruby subpackage and a subpackage requiring narray. However from the upstream point of view this is rather unfortunate. The plug-ins are examples, they are not meant to be *used* (all perform the same function). If one installs the interpreter for a language one is interested in, one just gets as a benefit a working plug-in in that language as it becomes executable. The sample plug-ins could be even installed somewhere Gwyddion does not find them by default and the developer could be required to install them to ~/.gwyddion/plugins or elsewhere manually. But I can see no advantage in this extra hassle when it Just Works as it is. > These perl/ruby/python modules should certainly be in a > platform independent location (I would chose %{pkgdatadir}). Perhaps, if differing from every other installation is a good thing. What is the difference from, e.g., python itself? It has all .py files in /usr/lib64. > Wouldn't it be better if the perl/python/ruby modules where real > modules? No, but this needs an explanation. 1. All the plug-in stuff is more or less legacy. We will support it while it will make sense, but I would rather avoid anything that could be interpreted as encouragement of its use. 2. The modules are intended for dealing with a dumb file format that is only encountered in temporary files processed by a Gwyddion plug-in. The file format is not used anywhere else. > Poking around in the source files, I have seen something that looks > like a file for vim, if you feel like it you can make another subpackage > for that file. Well, is there any precedent? Guidelines? I cannot find any vim subpackage (or vim-foo where foo is not a vim subpackage) nor anything in Fedora wiki. Note it is an auxiliary C syntax file which has to be sourced from a main file. A manual action on user's side is necessary, people should not get automatically highlighted Gwyddion types and funcs in all C files (unless they set it up so). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review