[Bug 187294] Review Request: gwyddion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]