[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-11 19:04 EST -------
(In reply to comment #25)

Still issues needing work:

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

* gwyddion-plugin-examples requires /usr/bin/env instead
  of ruby and python. I guess that's due to the shebang beeing 
  something like:
#! /usr/bin/env python
The python (and python modules, if needed) and ruby dependency should 
certainly be added (perl is allready picked up).

* rpmlint dislikes public domain but likes Public Domain. I guess you 
  should change it, or, alternatively, fill a bug report against rpmlint.

> And now to the dependency issue.  I'm afraid it's all upside down.
> 
> A perl module *extends* the interpreter, it does not *use* it.

I also uses it since the module is interpreted by the interpreter.

> For comparison with an area where things still work logically: how many -devel
> packages require gcc?  I will save you counting: Zero. None. Nada. Not a
single one.
> 
> Why is it so?  Because they do not really require gcc, they only provide
> extensions, although one needs gcc to use them in programs (or not to use, one
> needs gcc to compile stuff no matter he uses the extension or not).

I agree that it is a valid analogy. It is not exactly the same, 
however, as one may argue that another compiler than gcc 
may be used. (and also it is a runtime dependency, not only a 
compile time dependency, but it is irrelevant, since other -devel
packages, that are compile time dependencies are required).

> So the module -> interpreter dependency is not a hard dependency, but it still
> has a reason.  It is a convenience dependency.  We expect someone installing a
> perl module does it because
> 
> (a) he installs it to fulfill requirements of a perl script, and the dependency
> is redundant then but does not harm, or
> 
> (b) he wants to write perl scripts using this module, and here we save him some
>  work -- of course, if he wishes to write scripts that do not use any module he
> still has to install perl himself but that's just it.
> 
> Case (a) occurs when one installs gwyddion-plugin-examples (remember the
> dependency is a harmless redundancy here), case (b) does *not* occur because the
> module is not meant to be publicly used.

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. 

(example) plugins use them, so either they are packaged to be used or they
shouldn't be packaged at all, and the example plugins shouldn't be packaged, 
in that case.


But even though we are in case (b), I agree with your point 
about modules not stricly requiring interpreters (with the 
analogy with gcc, which could be extended to gcc/glibc-devel). 

perl dependencies are found automatically, however, so at least
the perl module should be in a separate package for that reason (or 
perl dependencies should be removed), since the -libs package 
shouldn't bring in perl.

So, regarding the requirement on interpreters and packaging in 
sub packages, I am not so sure now that it is a blocker
(although I still think it is better...). Maybe I'll ask on the
extras-list.


> [discursion]
> To see how far the expectation-based dependencies got from the real world, look
> at the `-devel requires pkgconfig' above.  The dependency stated by the policy
> is actually nonsense, one can compile programs using the library without
> pkgconfig just fine (only with more manual work, and certain people will frown
> upon you, etc.).  The real dependency is that a program whose configure script
> uses pkgconfig requires pkgconfig to build.
> [/discursion]

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?

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