[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 yeti at physics.muni.cz  2006-09-07 20:21 EST -------
(In reply to comment #17)
> I don't really get what you mean with 'upstream point of view'. If they
> are examples they shouldn't be installed (but shipped in docs or the like). 
> If they are usefull they should be packaged correctly.

Well, what's for example in /usr/share/cvs/contrib then (or other contrib dirs)?
 Mere examples?  But they cause cvs -> tcsh dependency.  User executables?  But
they are not in PATH and they are [cite]REALLY UNSUPORTED[/cite].  Auxiliary
executables?  But they are not in libexec and they are not used by anything. 
Documentation?  But they are not in a documentation directory, and a perl script
is hardly documentation it's something that needs documentation itself.  Things
have various modes of use, not everything is black and white.

So to get somewhere, what is the scenario under which the current approach
actually breaks?  What is the problem users of the current package would
encounter?  Or at least, what forbids this mode of use?

I maintain the devel subpackage does not need perl, python nor ruby.  It is
however made ready to be used with them *if* one decides so.  Someone
implementing a perl script without perl and blaming the packagers for missing
dependencies when it doesn't run is exactly as ridiculous as someone writing an
TeX document without TeX and blaming the packagers for missing dependencies when
it doesn't compile to DVI.

> That's untrue.

By python I referred to `python':

$ rpm -ql python | grep '\.py$' | grep -c ^/usr/share
0
$ rpm -ql python | grep '\.py$' | grep -c ^/usr/lib64
550

> Internal modules are better in %_datadir,
> and some packages indeed use that place for their internal modules,
> just try
> find /usr/share/ -name '*.py'
> find /usr/share/ -name '*.pm

I tried it before and the key word is `some'.  There is more than 20x more .py
files in lib64 than in share on my system (some are indirectly arch-dependent,
but anyway).

It is not a problem to put the modules to %{_datadir} instead of %{_libdir}.  I
just think one has to have a reason to deviate from upstream.  And I cannot see
the reason when the consistency gain is only virtual.

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