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-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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review