(In reply to comment #4)
> The License tag is GNU GPL because the license is GNU GPL. In addition in
> subpackage devel it reads `GNU GPL, parts public domain' now, because
> significant parts are in public domain.
In that case the licence tag should be
License: GPL

(In reply to comment #6)
> In that case the licence tag should be
> License: GPL
If everyone likes to repeat the common `GNU license' mistake just with the
second part of the name this time (there are dozens of SomeProgram General
Public Licenses that are not GNU GPL), if everyone thinks that `GPL' actually
denotes something, or that it should be put to the License field even it does
not mean anything, or that something should be put into the License field even
if the license of a large part of the software if very different, and above all
that the proper license acronym `GNU GPL' cannot be there, well, I can put GPL
or cauliflower or whatever there, no problem, the tag is obviously not supposed
to mean anything. But it isn't a technical issue so I won't make new src.rpm
now just to mangle one tag.

Using GPL instead of GNU GPL is a matter of convention.
If there is a mix of GPL and public domain code, the resulting subpackage
is covered by the GPL. However if you want to make clear which part
of the subpackage are under which licence, you can add a file explaining
more precisely the licences of the different parts of that subpackage, and
put it in %docs.
If you can isolate the parts that are public domain in a subpackage,
then the licence may be public domain for that subpackage.
Licence issues are not technical issues, but they are as important as
technical issues.
As a side note, you can omit the Licence: tag from subpackages
when it is the same than the licence of the main package.

What info is needed from me?
OK, maybe this info is needed: I will update the package complying with the
Fedora GNU GPL naming convention once Gwyddion 1.99.8 is released.
I abandoned the idea to get Gwyddion to FE fast after the two+ months of no
reaction to the initial submission (of the old stable version). I will not
support any pre-2.0 version therefore I don't want them to actually appear in
FE. And the closer the thing your review is to the real thing the better for
the review.

(In reply to comment #9)
> What info is needed from me?
No info is needed, but if I am not mistaken, NEEDINFO_REPORTER is
set when waiting for something by the initial submitter, that's
why I set it on that review (the aim is to help potential
reviewers know what the status of the review is).
> OK, maybe this info is needed: I will update the package complying with the
> Fedora GNU GPL naming convention once Gwyddion 1.99.8 is released.
>
> I abandoned the idea to get Gwyddion to FE fast after the two+ months of no
> reaction to the initial submission (of the old stable version). I will not
> support any pre-2.0 version therefore I don't want them to actually appear in
> FE. And the closer the thing your review is to the real thing the better for
> the review.
Thanks for the info.
Anyway since at least one upstream release is required for things
to move on, I think that setting the status to NEEDINFO_REPORTER is
the right thing to do. But do it only if it seems relevant to you.

i am not a sponsor, so I cannot approve the package but I have
some comments:
gwyddion-devel shouldn't own %{_libdir}/pkgconfig, but instead
Requires: pkgconfig
The shebangs removal seems to be done now, so the following is certainly
not relevant anymore (as said in the comment ;-):
# Remove shbangs from modules (upstream 1.99.8 will fix that)
sed -i '1s/^#!.*//' ruby/gwyddion/dump.rb python/Gwyddion/dump.py
For the desktop file you should have a look at:
http://fedoraproject.org/wiki/Packaging/Guidelines#head-254ddf07aae20a23ced8cecc219d8f73926e9755
There is something very strange, an include file below %_libdir:
/usr/lib/gwyddion/include/gwyconfig.h
I guess it is there because it is a generated include file so it
could include some platform-dependant informations... I have seen
that other libraries do the same, so I guess it is ok.
There is a missing Requires on ruby and python in -devel (I would
have guessed that they were autodetected, but that's not
the case???).
However, the plugins should certainly be in a separate subpackage,
called maybe gwyddion-plugin-examples, together with all the
internal ruby/perl/python modules. Another benefit of doing
a subpackage is that this subpackage could have only
code in the public domain (as it seems to me, but I haven't checked
everything) and could have a a licence marked as such.
These perl/ruby/python modules should certainly be in a
platform independent location (I would chose %{pkgdatadir}).
Since the perl module is an internal module, the man page should
certainly not be shipped, and the automatically determined
Provides perl(Gwyddion::dump) should not be present
Removing the provides may be achieved by
%define __perl_provides %{nil}
Wouldn't it be better if the perl/python/ruby modules where real
modules?
I am not convinced that the -devel package should require the base package,
if plugin examples are removed.
but it should certainly require the libs package, so I propose changing
Requires: %{name} = %{version}
to
Requires: %{name}-libs = %{version}-%{release}
The %post/%postun should be for the libs subpackage and not the main package.
There are %post scriptlets missing for mime handling, you should have
a look at
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-de6770dd9867fcd085a73a4700f6bcd0d10294ef
and
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-5f93ed83c968bb73b052c06ba0d7139e28f35d93
Otherwise it built and run on a Fc devel i386.
If I'm not wrong you are the upstream for this project,
maybe you could supply an example data file gwyddion can
handle for potential users to test.
Poking around in the source files, I have seen something that looks
like a file for vim, if you feel like it you can make another subpackage
for that file.

(still working on the technical points)
(In reply to comment #13)
> If I'm not wrong you are the upstream for this project,
> maybe you could supply an example data file gwyddion can
> handle for potential users to test.
I am indeed upstream. If you mean to supply in the package, I don't think it's
a good idea (they tend to be large, interested people tend to have lots of SPM
files themselves, and one can just import a PNG, JPEG, TIFF, ..., as a [bogus]
heightfield to play with the tools). If you mean it generally, a handful of
sample files is available on the web: http://gwyddion.net/download.php#sample-files

(In reply to comment #13)
Part I: Fixed stuff.
Spec URI: http://gwyddion.net/download/test/gwyddion.spec
SRPM URI: http://gwyddion.net/download/test/gwyddion-1.99.9-2.src.rpm
* Thu Sep 07 2006 David Necas (Yeti) <yeti@physics.muni.cz> - 1.99.9-2
- Removed `remove shbangs from modules', not needed anymore
- Fixed requirements of devel subpackage: require libs, not main; require
pkgconfig; added missing gtkglext-devel (required since we build with it)
- Don't own %%{_libdir}/pkgconfig directory
- Avoided automated Provides: perl(Gwyddion::dump)
- Moved ldconfig execution to libs subpackage scriptlet
- Added desktop, MIME database handling scriptlets from Fedora wiki
- Patch ltmain.sh instead of ex-post .la file removal (taken from FreeBSD port)
> gwyddion-devel shouldn't own %{_libdir}/pkgconfig, but instead
> Requires: pkgconfig
Fixed.
> The shebangs removal seems to be done now, so the following is certainly
> not relevant anymore (as said in the comment ;-):
> # Remove shbangs from modules (upstream 1.99.8 will fix that)
> sed -i '1s/^#!.*//' ruby/gwyddion/dump.rb python/Gwyddion/dump.py
Fixed.
> For the desktop file you should have a look at:
>
http://fedoraproject.org/wiki/Packaging/Guidelines#head-254ddf07aae20a23ced8cecc219d8f73926e9755
Hopefully fixed.
> There is something very strange, an include file below %_libdir:
> /usr/lib/gwyddion/include/gwyconfig.h
> I guess it is there because it is a generated include file so it
> could include some platform-dependant informations... I have seen
> that other libraries do the same, so I guess it is ok.
Yes, it is a page taken from GLib book and it is there exactly for
this reason, although it currently contains no *architecture*-dependent
bits. But one should be able to install for example 32bits
gwyddion libs with GtkGLExt enabled and 64bit with GtkGLExt disabled
(not that concerns Fedora much but it explains the file).
> Since the perl module is an internal module, the man page should
> certainly not be shipped, and the automatically determined
> Provides perl(Gwyddion::dump) should not be present
>
> Removing the provides may be achieved by
> %define __perl_provides %{nil}
Fixed.
> I am not convinced that the -devel package should require the base package,
> if plugin examples are removed.
> but it should certainly require the libs package, so I propose changing
> Requires: %{name} = %{version}
> to
> Requires: %{name}-libs = %{version}-%{release}
Fixed.
> The %post/%postun should be for the libs subpackage and not the main package.
Fixed.
> There are %post scriptlets missing for mime handling, you should have
> a look at
>
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-de6770dd9867fcd085a73a4700f6bcd0d10294ef> and
>
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-5f93ed83c968bb73b052c06ba0d7139e28f35d93
Hopefully fixed.

(In reply to comment #13)
Part II: Unclear stuff.
> There is a missing Requires on ruby and python in -devel (I would
> have guessed that they were autodetected, but that's not
> the case???).
> However, the plugins should certainly be in a separate subpackage,
> called maybe gwyddion-plugin-examples, together with all the
> internal ruby/perl/python modules. Another benefit of doing
> a subpackage is that this subpackage could have only
> code in the public domain (as it seems to me, but I haven't checked
> everything) and could have a a licence marked as such.
The most clean solution from the packaging point of view perhaps would be to
split the plug-in stuff by language and require individual interpreters in the
subpackages. In fact, since there are two kinds of ruby plug-ins, there should
be a plain ruby subpackage and a subpackage requiring narray.
However from the upstream point of view this is rather unfortunate. The
plug-ins are examples, they are not meant to be *used* (all perform the same
function). If one installs the interpreter for a language one is interested in,
one just gets as a benefit a working plug-in in that language as it becomes
executable.
The sample plug-ins could be even installed somewhere Gwyddion does not find
them by default and the developer could be required to install them to
~/.gwyddion/plugins or elsewhere manually. But I can see no advantage in this
extra hassle when it Just Works as it is.
> These perl/ruby/python modules should certainly be in a
> platform independent location (I would chose %{pkgdatadir}).
Perhaps, if differing from every other installation is a good thing. What is
the difference from, e.g., python itself? It has all .py files in /usr/lib64.
> Wouldn't it be better if the perl/python/ruby modules where real
> modules?
No, but this needs an explanation.
1. All the plug-in stuff is more or less legacy. We will support it while it
will make sense, but I would rather avoid anything that could be interpreted as
encouragement of its use.
2. The modules are intended for dealing with a dumb file format that is only
encountered in temporary files processed by a Gwyddion plug-in. The file format
is not used anywhere else.
> Poking around in the source files, I have seen something that looks
> like a file for vim, if you feel like it you can make another subpackage
> for that file.
Well, is there any precedent? Guidelines? I cannot find any vim subpackage (or
vim-foo where foo is not a vim subpackage) nor anything in Fedora wiki.
Note it is an auxiliary C syntax file which has to be sourced from a main file.
A manual action on user's side is necessary, people should not get
automatically highlighted Gwyddion types and funcs in all C files (unless they
set it up so).

(In reply to comment #16)
> (In reply to comment #13)
>
>
> The most clean solution from the packaging point of view perhaps would be to
> split the plug-in stuff by language and require individual interpreters in the
> subpackages. In fact, since there are two kinds of ruby plug-ins, there should
> be a plain ruby subpackage and a subpackage requiring narray.
>
> However from the upstream point of view this is rather unfortunate. The
> plug-ins are examples, they are not meant to be *used* (all perform the same
> function). If one installs the interpreter for a language one is interested in,
> one just gets as a benefit a working plug-in in that language as it becomes
> executable.
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.
> The sample plug-ins could be even installed somewhere Gwyddion does not find
> them by default and the developer could be required to install them to
> ~/.gwyddion/plugins or elsewhere manually. But I can see no advantage in this
> extra hassle when it Just Works as it is.
Then it should work as it is, but it shouldn't prevent from doing a
clean package. Splitting out a gwyddion-perl-plugin, and so on for
other languages wouldn't do any harm and would be more sensible
for packaging.
> > These perl/ruby/python modules should certainly be in a
> > platform independent location (I would chose %{pkgdatadir}).
>
> Perhaps, if differing from every other installation is a good thing. What is
> the difference from, e.g., python itself? It has all .py files in /usr/lib64.
That's untrue. Perl and python have 2 macros, one for noarch and
the other for arch dependent stuff. noarch is in /usr/lib/ even
on x64. You can use /usr/lib instead of /usr/share but /usr/share
is cleaner (and I believe that the use of lib for arch independent things
comes from past uses). 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'
> No, but this needs an explanation.
>
> 1. All the plug-in stuff is more or less legacy. We will support it while it
> will make sense, but I would rather avoid anything that could be interpreted as
> encouragement of its use.
Once again, if it is packaged, it should be done rightly, even
if it is different from upstream, or it shouldn't be packaged at
all. The best would be to install the modules like any other
module. For perl, however, there is no support upstream for
a classical module install (with Makefile.PL and the like).
So just copying them in a relevant location is all we can do
in fedora (you could also add a Makefile.PL, and patch the
build system to integrate it cleanly, but it is more work
and, as a reviewer I think it shouldn't be a blocker).
In the general case, the choices done upstream are not necessarily
the same that are done when packaging. When packaging, there
should be an adaptation of the package to the distribution.
Upstream is sometime too generic, and specific things are to
be done. When packaging in fedora you may have to change your
point of view and do some things differently than upstream.
Only on relevant details, of course.
> 2. The modules are intended for dealing with a dumb file format that is only
> encountered in temporary files processed by a Gwyddion plug-in. The file format
> is not used anywhere else.
So if plugins are allowed these modules are usefull. Once again,
since there is no support upstream they should be packaged simply.
> > Poking around in the source files, I have seen something that looks
> > like a file for vim, if you feel like it you can make another subpackage
> > for that file.
>
> Well, is there any precedent? Guidelines? I cannot find any vim subpackage (or
> vim-foo where foo is not a vim subpackage) nor anything in Fedora wiki.
You are indeed right. That's very strange as there are a lot of
emacs related subpackages. There is no precedent, but we could
make one. If you don't feel like it, I guess the best would be
to ship the .vim file in a %docs section. If you know vim enough
you can also do a subpackage which would hold the file in a
suitable directory. I have another package with a .vim file in
%docs installed.
> Note it is an auxiliary C syntax file which has to be sourced from a main file.
> A manual action on user's side is necessary, people should not get
> automatically highlighted Gwyddion types and funcs in all C files (unless they
> set it up so).
Ok. I don't know how such file work, but if it is better in the
vim hierarchy it could be there. Not a blocker in my opinion,
just a bonus.

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

OK, there is in fact a breakage scenario, albeit quite different: If a 3rd party
writes a plug-in and wants to distribute it (the scenario I'd rather avoid), it
now requires the devel subpackage instead of runtime, because the langauage
modules are in devel.
To guarantee executability of plug-ins, the main package has to require (or
contain) all the perl, python, ruby, ..., modules. But even then the perl,
python or ruby dependency is redundant. The main package does not use them, it
merely provides/requires modules. Any 3d party plug-in has to require its own
interpreter so interpreter dependencies are satisfied.

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

(In reply to comment #20)
> 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.
The dependencies are always met. Any 3rd party perl plug-in requires perl
itself as any other perl script does. Any 3rd party python plug-in requires
python itself, etc.
The dependency chain is
plug-in -> gwyddion, perl
not
plug-in -> gwyddion -> perl
Anyway, I did some less controversial changes meanwhile:
Spec URI: http://gwyddion.net/download/test/gwyddion.spec
SRPM URI: http://gwyddion.net/download/test/gwyddion-1.99.9-3.src.rpm
* Fri Sep 08 2006 David Necas (Yeti) <yeti@physics.muni.cz> - 1.99.9-3
- Moved auxiliary plug-in modues to libs subpackage to fix dependency of
modules on devel
- Added gwyddion.vim to devel as documentation

(In reply to comment #21)
> (In reply to comment #20)> The dependencies are always met. Any 3rd party perl plug-in requires perl
> itself as any other perl script does. Any 3rd party python plug-in requires
> python itself, etc.
Indeed this should be the case, but the gwyddion internal
modules requires the interpreter, so they should pull it in.
> The dependency chain is
>
> plug-in -> gwyddion, perl
>
> not
>
> plug-in -> gwyddion -> perl
Not quite. The dependency chain is
plug-in -> gwyddion 'internal' module usefull externally,
unfortunately not packaged as a normal perl module -> perl
Otherwise, you can simplify the spec file by having
%{_libexecdir}/%{name}/
in the %files section of the subpackage that holds the plugins.
Indeed nothing under %{pkglibexecdir}/ is needed in other
subpackage.
The files section for doc may also be simplified to
%doc %{_datadir}/gtk-doc/html/
and you can drop the
%define gtkdocdir %{_datadir}/gtk-doc/html
similarly, you can have
%{_datadir}/%{name}/
in -libs
and
%{_includedir}/%{name}/
in -devel and drop the corresponding defines.
Other simplifications using the same trick are also possible,
like
%{pkglibdir}/ruby/
instead of
%{pkglibdir}/ruby/gwyddion/*
%dir %{pkglibdir}/ruby/gwyddion
%dir %{pkglibdir}/ruby
and
%{pkglibdir}/modules/
%dir %{pkglibdir}
for the whole %files modules section, and other you can find by yourself.
If you prefer to keep the extensive list, I have nothing against
it, both approaches have merits and faults. Indeed a short list
is more readable, while an extensive list allows to know when
something changed. However, you should replace everywhere things like
%{pkglibdir}/python/Gwyddion/*
%dir %{pkglibdir}/python/Gwyddion
by the equivalent and simpler
%{pkglibdir}/python/Gwyddion/
(note the the trailing / is optional, but it helps a lot since it shows
that it is a directory).
Another comment, it seems to me that gwyddion-doc shouldn't own
%{_datadir}/gtk-doc/
but it issems to be casually done by other packages, so it may be
kept as is.

(In reply to comment #22)
> Indeed this should be the case, but the gwyddion internal
> modules requires the interpreter, so they should pull it in.
The presence or absence of the interpreters has absolutely no effect of the
function of the main package. So how it comes it requires it?
It starts having an effect only after you add something else -- that however
requires the appropriate interpreter itself.
> Not quite. The dependency chain is
>
> plug-in -> gwyddion 'internal' module usefull externally,
> unfortunately not packaged as a normal perl module -> perl
Do you mean mean a perl script requires perl indirectly via modules it uses?
Does it imply if a perl script uses no modules it does not require perl?
The direct plug-in -> perl dependency obviously exists, so listing it elsewhere
down the chain is redundant.
> Otherwise, you can simplify the spec file by having
> ...
Well, I prefer the explicit form. Also if installed directories contain files,
I prefer
%{pkglibdir}/somedir/*
%dir %{pkglibdir}/somedir
to
%{pkglibdir}/somedir/
as the former fails when nothing gets installed to somedir by accident while the
latter happily packages empty directory.
> Another comment, it seems to me that gwyddion-doc shouldn't own
> %{_datadir}/gtk-doc/
> but it issems to be casually done by other packages, so it may be
> kept as is.
This surfaced on FE list more than once, but I don't recall any good solution.
The directory is primarily owned by gtk-doc, but
Requires: gtk-doc
is wrong because the documentation is already compiled to HTML and does not
require gtk-doc.
Requires: %{_datadir}/gtk-doc
is wrong for the same reason (could be fixed by adding it to filesystem or a
similar base package). So AFAIK all packages that own subdirectories of this
directory currently own it too.

(In reply to comment #23)
> (In reply to comment #22)
> > Indeed this should be the case, but the gwyddion internal
> > modules requires the interpreter, so they should pull it in.
>
> The presence or absence of the interpreters has absolutely no effect of the
> function of the main package. So how it comes it requires it?
If I do a require for the Gwyddion::dump, it won't work without
perl. It is true that the script should require perl (although
it may be a script which is not packaged as a rpm) but Gwyddion::dump
require perl too. And it is in -libs.
> It starts having an effect only after you add something else -- that however
> requires the appropriate interpreter itself.
A perl module requires perl at any time. (If it was in doc it would be
different, however).
Moreover having modules packaged separately helps user chosing the right
packages. But in any case it is working around the brokeness of not
having those modules properly packaged as modules.
> Do you mean mean a perl script requires perl indirectly via modules it uses?
> Does it imply if a perl script uses no modules it does not require perl?
The plugin could be not packaged, but a simple script.
In the general case, I think that a perl script requires perl due
to the shebang which brings in the interpreter. But it doesn't stop
the module from requiring perl.
> The direct plug-in -> perl dependency obviously exists, so listing it elsewhere
> down the chain is redundant.
No. The perl module requires perl and don't requires anything that
requires perl. The redundant dependency could be the script
direct dependency on perl, but since it is auto-generate, it doesn't hurt.
> > Otherwise, you can simplify the spec file by having
> > ...
>
> Well, I prefer the explicit form. Also if installed directories contain files,
> I prefer
>
> %{pkglibdir}/somedir/*
> %dir %{pkglibdir}/somedir
>
> to
>
> %{pkglibdir}/somedir/
>
> as the former fails when nothing gets installed to somedir by accident while the
> latter happily packages empty directory.
Right, thanks, I ignored that. It is perfectly right in that case.
> > Another comment, it seems to me that gwyddion-doc shouldn't own
> > %{_datadir}/gtk-doc/
> > but it issems to be casually done by other packages, so it may be
> > kept as is.
>
> This surfaced on FE list more than once, but I don't recall any good solution.
> The directory is primarily owned by gtk-doc, but
>
> Requires: gtk-doc
>
> is wrong because the documentation is already compiled to HTML and does not
> require gtk-doc.
>
> Requires: %{_datadir}/gtk-doc
>
> is wrong for the same reason (could be fixed by adding it to filesystem or a
> similar base package). So AFAIK all packages that own subdirectories of this
> directory currently own it too.
Yes, I understand the issue. There is a thread on similar issue
currently. I think you do it as rightly as possible.
In my opinion having the example plugins packaged in the -devel
subpackage is also an error they should be in a separate
package, like
gwyddion-plugin-examples
They are not -devel like stuff, but really an example (which may
happen to be usefull so isn't in doc). Then you can have an
explicit %description for that subpackage. And also the perl/python
and so on interpreters won't be installed when installing the -devel
subpackage.

Spec URI: http://gwyddion.net/download/test/gwyddion.spec
SRPM URI: http://gwyddion.net/download/test/gwyddion-1.99.9-4.src.rpm
* Mon Sep 11 2006 David Necas (Yeti) <yeti@physics.muni.cz> - 1.99.9-4
- Split plug-ins from devel to plugin-examples
- Added gwyddion-1-99-9-crashes.patch fixing several crashes (from upstream)
And now to the dependency issue. I'm afraid it's all upside down.
A perl module *extends* the interpreter, it does not *use* it.
A Perl module alone is equally useless with or without the interpreter, the only
useful thing is something that uses both the interpreter and the module, i.e., a
program.
If you do not accept `I want to write perl programs/run 3rd party perl programs
but don't have the perl interpreter' as a packaging problem (such a `problem'
could be only `solved' by mandatory installation of every piece of software in
the Universe), no case when depencencies are unmet can arise. And when no such
case can arise, where is the dependency?
For comparison with an area where things still work logically: how many -devel
packages require gcc? I will save you counting: Zero. None. Nada. Not a single one.
Why is it so? Because they do not really require gcc, they only provide
extensions, although one needs gcc to use them in programs (or not to use, one
needs gcc to compile stuff no matter he uses the extension or not).
So the module -> interpreter dependency is not a hard dependency, but it still
has a reason. It is a convenience dependency. We expect someone installing a
perl module does it because
(a) he installs it to fulfill requirements of a perl script, and the dependency
is redundant then but does not harm, or
(b) he wants to write perl scripts using this module, and here we save him some
work -- of course, if he wishes to write scripts that do not use any module he
still has to install perl himself but that's just it.
Case (a) occurs when one installs gwyddion-plugin-examples (remember the
dependency is a harmless redundancy here), case (b) does *not* occur because the
module is not meant to be publicly used.
[discursion]
To see how far the expectation-based dependencies got from the real world, look
at the `-devel requires pkgconfig' above. The dependency stated by the policy
is actually nonsense, one can compile programs using the library without
pkgconfig just fine (only with more manual work, and certain people will frown
upon you, etc.). The real dependency is that a program whose configure script
uses pkgconfig requires pkgconfig to build.
[/discursion]

(In reply to comment #25)
Still issues needing work:
* I tested that the modules subpackage can be merged with the libs
subpackage without any rpmlint warning and it certainly makes sense to
merge those 2 subpackages.
* gwyddion-plugin-examples requires /usr/bin/env instead
of ruby and python. I guess that's due to the shebang beeing
something like:
#! /usr/bin/env python
The python (and python modules, if needed) and ruby dependency should
certainly be added (perl is allready picked up).
* rpmlint dislikes public domain but likes Public Domain. I guess you
should change it, or, alternatively, fill a bug report against rpmlint.
> And now to the dependency issue. I'm afraid it's all upside down.
>
> A perl module *extends* the interpreter, it does not *use* it.
I also uses it since the module is interpreted by the interpreter.
> For comparison with an area where things still work logically: how many -devel
> packages require gcc? I will save you counting: Zero. None. Nada. Not a
single one.
>
> Why is it so? Because they do not really require gcc, they only provide
> extensions, although one needs gcc to use them in programs (or not to use, one
> needs gcc to compile stuff no matter he uses the extension or not).
I agree that it is a valid analogy. It is not exactly the same,
however, as one may argue that another compiler than gcc
may be used. (and also it is a runtime dependency, not only a
compile time dependency, but it is irrelevant, since other -devel
packages, that are compile time dependencies are required).
> So the module -> interpreter dependency is not a hard dependency, but it still
> has a reason. It is a convenience dependency. We expect someone installing a
> perl module does it because
>
> (a) he installs it to fulfill requirements of a perl script, and the dependency
> is redundant then but does not harm, or
>
> (b) he wants to write perl scripts using this module, and here we save him some
> work -- of course, if he wishes to write scripts that do not use any module he
> still has to install perl himself but that's just it.
>
> Case (a) occurs when one installs gwyddion-plugin-examples (remember the
> dependency is a harmless redundancy here), case (b) does *not* occur because the
> module is not meant to be publicly used.
I disagree with that, I think that we are in case (b). Even though
it is not meant to be publicly used from the upstream point of
view, in my opinion it is something that should be provided to
the fedora user in case he wants to use the module. It is a regular
module from the fedora point of view. If it could be easily packaged
like a regular module it would have been better. Since it is too much
work i think not having the modules as regular modules isn't a blocker.
(example) plugins use them, so either they are packaged to be used or they
shouldn't be packaged at all, and the example plugins shouldn't be packaged,
in that case.
But even though we are in case (b), I agree with your point
about modules not stricly requiring interpreters (with the
analogy with gcc, which could be extended to gcc/glibc-devel).
perl dependencies are found automatically, however, so at least
the perl module should be in a separate package for that reason (or
perl dependencies should be removed), since the -libs package
shouldn't bring in perl.
So, regarding the requirement on interpreters and packaging in
sub packages, I am not so sure now that it is a blocker
(although I still think it is better...). Maybe I'll ask on the
extras-list.
> [discursion]
> To see how far the expectation-based dependencies got from the real world, look
> at the `-devel requires pkgconfig' above. The dependency stated by the policy
> is actually nonsense, one can compile programs using the library without
> pkgconfig just fine (only with more manual work, and certain people will frown
> upon you, etc.). The real dependency is that a program whose configure script
> uses pkgconfig requires pkgconfig to build.
> [/discursion]
If I remember well, the reason why pkgconfig should be a requires has
been argued on the lists. I don't remember the reasons, but if you
disagree with that idea, you can rise the issue on fedora-extras list.
Anyway it always makes sense to Requires pkgconfig for the pkgconfig
directory owning. Do you disagree with that?

Spec URI: http://gwyddion.net/download/test/gwyddion.spec
SRPM URI: http://gwyddion.net/download/test/gwyddion-1.99.9-5.src.rpm
* Tue Sep 12 2006 David Necas (Yeti) <yeti@physics.muni.cz> - 1.99.9-5
- Capitalized plugin-examples license to `Public Domain' to placate rpmlint
- Re-merged modules to libs.
- Added explicit interpreter dependencies to plugin-examples.
(In reply to comment #26)
> * I tested that the modules subpackage can be merged with the libs
> subpackage without any rpmlint warning and it certainly makes sense to
> merge those 2 subpackages.
You are right. I wonder what rpmlint version I was using...
> * gwyddion-plugin-examples requires /usr/bin/env instead
> of ruby and python.
Fixed.
> * rpmlint dislikes public domain but likes Public Domain.
Whatever rpmlint likes.
> > A perl module *extends* the interpreter, it does not *use* it.
>
> I also uses it since the module is interpreted by the interpreter.
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.
> I disagree with that, I think that we are in case (b). Even though
> it is not meant to be publicly used from the upstream point of
> view, in my opinion it is something that should be provided to
> the fedora user in case he wants to use the module. It is a regular
> module from the fedora point of view. If it could be easily packaged
> like a regular module it would have been better. Since it is too much
> work i think not having the modules as regular modules isn't a blocker.
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.
> If I remember well, the reason why pkgconfig should be a requires has
> been argued on the lists. I don't remember the reasons, but if you
> disagree with that idea, you can rise the issue on fedora-extras list.
> Anyway it always makes sense to Requires pkgconfig for the pkgconfig
> directory owning. Do you disagree with that?
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.
The point was that expectation-based dependencies (Recommends/Suggests in
Debian) and not hard dependencies are must be added with forethought.

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/)

I posted a message about our disagreement on fedora-extras-list,
but nobody responded something allowing to come to a decision.
Otherwise I found another issue, the icon for menu would
better be in %{_datadir}/icons/hicolor/48x48/apps
since it has then a location corresponding with the size.
Then you should run the appropriate snippets which regenerates
the hicolor icon cache.

I got one response, of Spot, backing my views:
Lemme make this clear.
If the user downloads something in your package/subpackage, and it
doesn't work because of a missing dependency (e.g. perl/python/ruby) not
present, then you screwed up. Don't assume your users have a sane
environment, or even that your users possess the faintest amount of
clue.

The plugin-examples subpackage requies everything necessary to run the programs
inside. So either I don't understand the sentence `If the user downloads
something in your package/subpackage' or it does work.
The model is still the same: to use a Perl program which is incidentally a
Gwyddion plug-in, one needs two things: Perl and Gwyddion. Perl is required for
all Perl programs and Gwyddion is required because it's Gwyddion plug-in. If
this is satisfied, nothing can break.

Reading mailing list discussions touching the relation between FE and the rest
of the world I gradually realized I do not identify with FE, its goals and the
course it is taking any more. Seeking sponsorship makes no sense in such a
situation therefore I am closing this bug as WONTFIX.
Thank you for your comments and I apologize for the wasted time.

(In reply to comment #33)
> Reading mailing list discussions touching the relation between FE and the rest
> of the world I gradually realized I do not identify with FE, its goals and the
> course it is taking any more. Seeking sponsorship makes no sense in such a
> situation therefore I am closing this bug as WONTFIX.
This bugreport may not be the perfect place, but could you give a
summary as to why FE don't suit you, in case it points at weaknesses
of the community?
> Thank you for your comments and I apologize for the wasted time.
Having packages enter fedora is only part of the job. Having packages
of the highest quality is another aim, even if they don't enter
fedora extras. And lastly attracting packagers is also an important
aim, but here it is a miss ;-).