[Bug 187294] Review Request: gwyddion

Thu Sep 7 21:43:37 UTC 2006

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 at free.fr  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.