[Bug 187294] Review Request: gwyddion

[bugzilla at redhat.com]

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-09 05:15 EST -------
(In reply to comment #23)
> (In reply to comment #22)
> > Indeed this should be the case, but the gwyddion internal
> > modules requires the interpreter, so they should pull it in.
> 
> The presence or absence of the interpreters has absolutely no effect of the
> function of the main package.  So how it comes it requires it?

If I do a require for the Gwyddion::dump, it won't work without
perl. It is true that the script should require perl (although
it may be a script which is not packaged as a rpm) but Gwyddion::dump
require perl too. And it is in -libs.

> It starts having an effect only after you add something else -- that however
> requires the appropriate interpreter itself.

A perl module requires perl at any time. (If it was in doc it would be 
different, however). 

Moreover having modules packaged separately helps user chosing the right
packages. But in any case it is working around the brokeness of not 
having those modules properly packaged as modules.

> Do you mean mean a perl script requires perl indirectly via modules it uses? 
> Does it imply if a perl script uses no modules it does not require perl?

The plugin could be not packaged, but a simple script. 

In the general case, I think that a perl script requires perl due
to the shebang which brings in the interpreter. But it doesn't stop
the module from requiring perl. 

> The direct plug-in -> perl dependency obviously exists, so listing it elsewhere
> down the chain is redundant.

No. The perl module requires perl and don't requires anything that
requires perl. The redundant dependency could be the script 
direct dependency on perl, but since it is auto-generate, it doesn't hurt.

> > Otherwise, you can simplify the spec file by having
> > ...
> 
> Well, I prefer the explicit form.  Also if installed directories contain files,
> I prefer
> 
> %{pkglibdir}/somedir/*
> %dir %{pkglibdir}/somedir
> 
> to 
> 
> %{pkglibdir}/somedir/
> 
> as the former fails when nothing gets installed to somedir by accident while the
> latter happily packages empty directory.

Right, thanks, I ignored that. It is perfectly right in that case.

> > Another comment, it seems to me that gwyddion-doc shouldn't own 
> > %{_datadir}/gtk-doc/
> > but it issems to be casually done by other packages, so it may be
> > kept as is.
> 
> This surfaced on FE list more than once, but I don't recall any good solution. 
> The directory is primarily owned by gtk-doc, but
> 
>   Requires: gtk-doc
> 
> is wrong because the documentation is already compiled to HTML and does not
> require gtk-doc.
> 
>   Requires: %{_datadir}/gtk-doc
> 
> is wrong for the same reason (could be fixed by adding it to filesystem or a
> similar base package).  So AFAIK all packages that own subdirectories of this
> directory currently own it too.

Yes, I understand the issue. There is a thread on similar issue 
currently. I think you do it as rightly as possible.


In my opinion having the example plugins packaged in the -devel
subpackage is also an error they should be in a separate
package, like
gwyddion-plugin-examples
They are not -devel like stuff, but really an example (which may
happen to be usefull so isn't in doc). Then you can have an 
explicit %description for that subpackage. And also the perl/python
and so on interpreters won't be installed when installing the -devel 
subpackage.

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