[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-12 05:59 EST -------
A quick note, there is a 
/sbin/ldconfig
which is certainly forgotten in %postun

(and another one, there are still dependencies on perl in -libs, but
it could be sorted out when there is an agreement on the split)

rpmlint output is now ignorable
W: gwyddion-devel no-dependency-on gwyddion
E: gwyddion-devel only-non-binary-in-usr-lib
W: gwyddion-plugin-examples no-documentation


(In reply to comment #27)

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

That was not my point. What I was saying is that, unlike -devel 
package which is needed at compile time only, modules are needed
at runtime, and are directly used (or run if you prefer) by the 
interpreter. Not important.
 

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

I don't want to force you to do anything but package things 
consistently. I don't have any problem with not packaging at all 
the modules and example plugins. But in case they are packaged 
they should be packaged such that they are easy to use by users, 
which means that what the best would be to have them available 
as classical modules. And if it is not the case, they should be 
packaged like modules.


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

That won't necessarily be a packaging problem. Indeed you have to chose
between alternatives regarding directory ownership, and none are pretty:

* add a package that only holds the directory (filesystem)
* depend on a package that holds the directory but also 
  provide other and maybe unneeded things (pkgconfig, automake 
  for /usr/share/aclocal/)
* have all the packages own the directory (/usr/share/gtk-doc/html/)



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