[Bug 187294] Review Request: gwyddion

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

 



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

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