Spec Name or Url: http://gwyddion.net/download/test/gwyddion.spec SRPM Name or Url: http://gwyddion.net/download/test/gwyddion-1.15-0.1.src.rpm Description: Hi, this is my first package and I am seeking for a sponsor. Gwyddion is a SPM (scanning probe microscopy) data visualization and interactive analysis tool written with Gtk+. To various extent, it can be used for other 2D data too.
A new version that actually builds on FC5 and devel (not just FC4 and FC3): Spec URI: http://gwyddion.net/download/test/gwyddion.spec SRPM URI: http://gwyddion.net/download/test/gwyddion-1.15-0.3.src.rpm Still waiting for a review...
Updated to new upstream package: Spec URI: http://gwyddion.net/download/test/gwyddion.spec SRPM URI: http://gwyddion.net/download/test/gwyddion-1.16-0.1.src.rpm
rpmlint on your source package returns W: gwyddion invalid-license GNU GPL
Package was updated to the devel branch (1.99.7), split to app + libs + modules to stop the hundreds of rpmlint complaints about versioned and unversioned libs in the same package. Spec URI: http://gwyddion.net/download/test/gwyddion.spec SRPM URI: http://gwyddion.net/download/test/gwyddion-1.99.7-0.2.src.rpm 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.
Since you are seeking a sponsor, you may wish to review: http://fedoraproject.org/wiki/Extras/HowToGetSponsored (adding FE-NEEDSPONSOR blocking bug)
(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.
New version is available at: Spec URI: http://gwyddion.net/download/test/gwyddion.spec SRPM URI: http://gwyddion.net/download/test/gwyddion-1.99.8-1.src.rpm * Thu Aug 10 2006 David Necas (Yeti) <yeti.cz> - 1.99.8-1 - Changed `GNU GPL' to `GPL' to placate rpmlint - Fixed requirement of gtk2-devel 2.2 -> 2.6 in devel package - Removed python abi requirement as it is only needed in FC3- - Set plug-in permissions in the filesystem since they are not set in %%files
New upstream version is available, so I repackaged the src.rpm, there are no other changes: Spec URI: http://gwyddion.net/download/test/gwyddion.spec SRPM URI: http://gwyddion.net/download/test/gwyddion-1.99.9-1.src.rpm * Thu Sep 07 2006 David Necas (Yeti) <yeti.cz> - 1.99.9-1 - rebuilt with upstream 1.99.9
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.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.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.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.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/)
Spec URI: http://gwyddion.net/download/test/gwyddion.spec SRPM URI: http://gwyddion.net/download/test/gwyddion-2.0-1.src.rpm * Fri Oct 13 2006 David Necas (Yeti) <yeti.cz> - 2.0-1 - Updated for upstream 2.0, changing %%libso style to normal library versioning - Removed extra ldconfig from main pkg postun - Got rid of env in shbangs
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 ;-).
*** This bug has been marked as a duplicate of bug 886112 ***