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 pertusus@xxxxxxx 2006-09-07 17:43 EST ------- (In reply to comment #16) > (In reply to comment #13) > > > 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. I don't really get what you mean with 'upstream point of view'. If they are examples they shouldn't be installed (but shipped in docs or the like). If they are usefull they should be packaged correctly. > 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. Then it should work as it is, but it shouldn't prevent from doing a clean package. Splitting out a gwyddion-perl-plugin, and so on for other languages wouldn't do any harm and would be more sensible for packaging. > > 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. That's untrue. Perl and python have 2 macros, one for noarch and the other for arch dependent stuff. noarch is in /usr/lib/ even on x64. You can use /usr/lib instead of /usr/share but /usr/share is cleaner (and I believe that the use of lib for arch independent things comes from past uses). Internal modules are better in %_datadir, and some packages indeed use that place for their internal modules, just try find /usr/share/ -name '*.py' find /usr/share/ -name '*.pm' > 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. Once again, if it is packaged, it should be done rightly, even if it is different from upstream, or it shouldn't be packaged at all. The best would be to install the modules like any other module. For perl, however, there is no support upstream for a classical module install (with Makefile.PL and the like). So just copying them in a relevant location is all we can do in fedora (you could also add a Makefile.PL, and patch the build system to integrate it cleanly, but it is more work and, as a reviewer I think it shouldn't be a blocker). In the general case, the choices done upstream are not necessarily the same that are done when packaging. When packaging, there should be an adaptation of the package to the distribution. Upstream is sometime too generic, and specific things are to be done. When packaging in fedora you may have to change your point of view and do some things differently than upstream. Only on relevant details, of course. > 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. So if plugins are allowed these modules are usefull. Once again, since there is no support upstream they should be packaged simply. > > 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. You are indeed right. That's very strange as there are a lot of emacs related subpackages. There is no precedent, but we could make one. If you don't feel like it, I guess the best would be to ship the .vim file in a %docs section. If you know vim enough you can also do a subpackage which would hold the file in a suitable directory. I have another package with a .vim file in %docs installed. > 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). Ok. I don't know how such file work, but if it is better in the vim hierarchy it could be there. Not a blocker in my opinion, just a bonus. -- 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