[Bug 187294] Review Request: gwyddion
bugzilla at redhat.com
bugzilla at redhat.com
Tue Sep 12 08:03:34 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 yeti at physics.muni.cz 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 at physics.muni.cz> - 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.
More information about the Fedora-package-review
mailing list