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-12 04:03 EST ------- Spec URI: http://gwyddion.net/download/test/gwyddion.spec SRPM URI: http://gwyddion.net/download/test/gwyddion-1.99.9-5.src.rpm * Tue Sep 12 2006 David Necas (Yeti) <yeti@xxxxxxxxxxxxxxx> - 1.99.9-5 - Capitalized plugin-examples license to `Public Domain' to placate rpmlint - Re-merged modules to libs. - Added explicit interpreter dependencies to plugin-examples. (In reply to comment #26) > * I tested that the modules subpackage can be merged with the libs > subpackage without any rpmlint warning and it certainly makes sense to > merge those 2 subpackages. You are right. I wonder what rpmlint version I was using... > * gwyddion-plugin-examples requires /usr/bin/env instead > of ruby and python. Fixed. > * rpmlint dislikes public domain but likes Public Domain. Whatever rpmlint likes. > > A perl module *extends* the interpreter, it does not *use* it. > > I also uses it since the module is interpreted by the interpreter. I'm not convinced the techincal details of how the interpreter is extended (it dlopens a shared library and calls some functions -- or it reads and interprets some high-level code) affect what consistutes a dependency. > I disagree with that, I think that we are in case (b). Even though > it is not meant to be publicly used from the upstream point of > view, in my opinion it is something that should be provided to > the fedora user in case he wants to use the module. It is a regular > module from the fedora point of view. If it could be easily packaged > like a regular module it would have been better. Since it is too much > work i think not having the modules as regular modules isn't a blocker. The work is not the problem for me. The problem is to introduce 3 more subpackages, each with a single module and README.Fedora saying something along the lines `This module was made public due to Fedora requirements, but do not actually use it.' This would be rather silly. > If I remember well, the reason why pkgconfig should be a requires has > been argued on the lists. I don't remember the reasons, but if you > disagree with that idea, you can rise the issue on fedora-extras list. > Anyway it always makes sense to Requires pkgconfig for the pkgconfig > directory owning. Do you disagree with that? I'm not bothered much by the expectation-based dependency in the case of pkgconfig, because the expectation is often right (unlike our case, although you don't agree) and pkgconfig is a small program without any further dependencies (unlike for example python). But to require a tool *only* to get a directory to put files to, that would be indeed a packaging problem IMO. The point was that expectation-based dependencies (Recommends/Suggests in Debian) and not hard dependencies are must be added with forethought. -- 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