[Bug 187294] Review Request: gwyddion

Fri Sep 8 08:27:05 UTC 2006

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