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@xxxxxxx 2006-09-08 04:27 EST ------- (In reply to comment #18) > 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. I certainly wouldn't have accepted that kind of packaging without disagreeing. And this is a core package, so there hasn't been any review. But others reviewers may disagree with me, it wouldn't be the first time that it happens ;-). Admitedly, this is not an easy choice, because this is code and doc. > 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? For the 'internal' modules, plugins dealing with the dump file format will have to require a -devel package. This is not what is done in most cases, it seems to me that it breaks the user expectations. So I think each internal modules should be in a distinct package with the interpreter name in the package name. Alternatively they may be in the main package, but the interpreters should be required. This is not the job of the users to have proper dependencies, it is the packager job. For the plugins, since they are more or less examples, I think that a subpackage containing all of them called gwyddion-plugin-examples which would require all the internal module packages could do the trick. You should anyway add a README file, called for example README.fedora or README.plugins explaining what you said here, something along: "Those plugins are examples of what can be done with plugins, and they all perform the same task. The use of plugins is discouraged, however, so you should use plugins only if you really need to." > 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. The internal modules and the plugins are not something done by users but shipped by pakckagers, so you, as a packager must ensure that the dependencies are met. > 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 Ok, that's because these are arch dependent modules. But look at the python modules in /usr/lib/python2.4, these are the noarch modules. Arch independent files should not be in arch-dependent dirs. You can prefer /usr/lib/something on 386 and x64, rather than /usr/share, like what is done for noarch python and perl packages, but don't put them in an arch-dependent directory. The case of your package is really different from the python case. python is an interpreter written in C, with many modules written in C, so arch dependent. Admitedly arch dependent part of a module may be mixed up with arch independent part of the same module, but noarch modules are in a distinct place. > 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). These are arch-dependent python modules. The gwyddion module is noarch and isn't a python module, it is an internal module. > 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. Arch independent files should not be in an arch-dependent directory. The FHS isn't very clear about where those files should be, but it shouldn't be in lib64: "/usr/lib<qual> performs the same role as /usr/lib for an alternate binary format, except that the symbolic links /usr/lib<qual>/sendmail and /usr/lib<qual>/X11 are not required. [26]" /usr/lib (for all the arches) and /usr/share seems to me to be possible places. I have checked what is currently done on my computer, and all the internal perl modules are in %_datadir, except one, which is arch-dependent. There are also more internal python modules in %_datadir, but I didn't checked whether all the ones in /usr/lib are all arch-dependent or not. -- 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