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-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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review