Spec URL: http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools.spec SRPM URL: http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools-1.12.0-2.fc6.src.rpm Description: This package contains tools to support the construction of tcltk widgets.
This package looks pretty good to me, but I don't really know much about R so there are a few questions to which we'll need to work out answers. First, the lone rpmlint complaint: E: R-widgetTools only-non-binary-in-usr-lib There are no noarch R packages in the distro, so I'm not sure if this is acceptable or if it's even possible to put these under /usr/share and have R find them. Does R have a a search path for modules or will it only look in _libdir? Now, some concerns about documentation: The files you list as %doc end up being packaged twice, once under R/library/widgetT9ools and once under /usr/share/doc. None of the documentation files under R/library/widgetTools show up as doc files in the final package. I don't know if this is a problem; it depends on whether the package will still function if those files are deleted.
E: R-widgetTools only-non-binary-in-usr-lib For this remark I asked spot at that time and he told me that it was not possible to avoid this complaint with some package. But maybe there is a trick that I do not know to avoid it... None of the documentation files under R/library/widgetTools show up as doc files in the final package. I don't know if this is a problem; it depends on whether the package will still function if those files are deleted. For this point, R is using a graphical interface on which you can see the different libraries that are set up for the program (that why there is the %post). Based on the spec of R-Matrix - R module ( https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241052 ) I have changed the %doc section to avoid this redundancy If you agree on these change then I will change my other spec file. SPEC : http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools.spec SRPM : http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools-1.12.0-3.fc6.src.rpm
Actually DESCRIPTION file is useless in packages. the command: $ rpm -q [package_name] --info already do this work. So, you SHOULD remove this file. However, there are some .pdf files which should be added as documentation files from /widgetTools/inst/doc/ subdirectories. Also, i see no license text or file in this package.
A few comments: It is possible to put noarch R packages into %{_datadir}/R/library, instead of in %{_libdir}/R/library (where arch-specific R packages should go). I had forgotten that this was possible, which is shameful, since I'm the person who enabled it. :P I'd argue that the DESCRIPTION is a useful %doc item.
(In reply to comment #3, Xavier) > Also, i see no license text or file in this package. Are you under the impression that this is mandatory? If there's a license file in the upstream tarball then it has to be included in the package. If upstream includes no license file then the package maintainer certainly doesn't have to manufacture one. (In reply to comment #4, Spot) > It is possible to put noarch R packages into %{_datadir}/R/library, instead of > in %{_libdir}/R/library (where arch-specific R packages should go). That's great; do you just do the usual R CMD INSTALL and give the other directory? Does this work for FC6 and F7? > I'd argue that the DESCRIPTION is a useful %doc item. I certainly agree; rpm -q --info certainly does not give the same information as is present in the DESCRIPTION file. I really don't understand why Xavier would make such a comment unless he didn't actually look at what's in the file.
(In reply to comment #5) > (In reply to comment #3, Xavier) > > Also, i see no license text or file in this package. > > Are you under the impression that this is mandatory? If there's a license file > in the upstream tarball then it has to be included in the package. If upstream > includes no license file then the package maintainer certainly doesn't have to > manufacture one. surely not, i just pasted a note. However, there're some packaging draft that talk about the why a license text is usefull. > > > (In reply to comment #4, Spot) > > It is possible to put noarch R packages into %{_datadir}/R/library, instead of > > in %{_libdir}/R/library (where arch-specific R packages should go). > > That's great; do you just do the usual R CMD INSTALL and give the other > directory? Does this work for FC6 and F7? > > > I'd argue that the DESCRIPTION is a useful %doc item. > > I certainly agree; rpm -q --info certainly does not give the same information as > is present in the DESCRIPTION file. I really don't understand why Xavier would > make such a comment unless he didn't actually look at what's in the file. i looked the file, and it's why I commented about that, if you look close, sure there's some things that dismatch between rpm -q [package-name] --info and DESCRIPTION are the maintainers, the date of the packaged and the packager, etc. AFAIK the maintainer of the package (rpm) which should be mentione is the fedoraproject (just my guess). Note that some end-users could be confused "who is who ?" or "what is what ?" here is a exmeple output of rpm -q [package_name] --info command: --------------------------------------------------------------- $ rpm -q glade2 --info Name : glade2 Relocations: (not relocatable) Version : 2.12.1 Vendor: Red Hat, Inc. Release : 5.fc6 Build Date: Fri 08 Sep 2006 01:03:55 PM AST Install Date: Thu 05 Jul 2007 12:56:02 PM AST Build Host: hs20-bc1-7.build.redhat.com Group : Development/Tools Source RPM: glade2-2.12.1-5.fc6.src.rpm Size : 5171445 License: GPL Signature : DSA/SHA1, Tue 03 Oct 2006 09:49:46 PM AST, Key ID b44269d04f2a6fd2 Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://glade.gnome.org/ Summary : A GTK+ GUI builder. Description : Glade is a free user interface builder for GTK+ and the GNOME GUI desktop. Glade can produce C source code. Support for C++, Ada95, Python, and Perl is also available, via external tools which process the XML interface description files output by GLADE. ------------------------------------------------------------------------------ Also, i'm wondering if a lil' packaging guideline for R package could be usefull
Based on the comments made by spot and tibbs there is the new spec file and the new srpm. I took me some time but I checked the set up and removal and both are working the folder are in /usr/share/R/library I have also checked with a second package (R-DynDoc) to see whatever the update of the help html interface is working (and it does :-)) The rpmlint is clean now and mock too. There are the lastest versions: SPEC : http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools.spec SRPM : http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools-1.12.0-4.fc6.src.rpm I do agree with Xavier on the fact that a R packaging guideline can be useful, especially because R package are not difficult to do but if we want them in constant quality we will need it. I have already made a spectemplate-R that I can changed to take into account these remarks and send to anyone who wants it. Regards P.
just a comment, The DESCRIPTION file is installed twice. in %{_docdir}/%{name}-%{version}/ and %{_datadir}/R/library/%{name}/ Sounds like a lining thing.
I took into account this comment, There are the new spec file and src.rpm SPEC http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools.spec SRPM http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools-1.12.0-5.fc6.src.rpm Thanks
This one looks much better. Oddly the spec file has become executable, which elicits the following from rpmlint: W: R-widgetTools strange-permission R-widgetTools.spec 0755 I don't think this is anything to worry about. I'm confused by the dependencies. This pachage seems to have no requirements besides /bin/sh needed to run the scriptlets. Shouldn't it depend on R as well as tcl and tk? The final package is mostly documentation. The whole package isn't huge so I don't think it's mandatory that it be split into a -doc subpackage and I know that R has its own internal documentation browser system, but I still have to wonder if the documentation in this package shouldn't be marked as %doc so a smaller --excludedocs installation is possible. The question is simple: does the package still work if you delete all of the documentation files. If so, those files should all be marked as %doc. And I certainly agree, guidelines for R packages would be a great idea as they would answer all of these questions I keep having. I, however, am certainly not the person who should be writing them. Review: * source files match upstream: 50c37833547bf50553a2bfe3a3426ec798eb066c29df9581f0ad50180a961974 widgetTools_1.12.0.tar.gz * package meets naming and versioning guidelines. * specfile is properly named, is cleanly written and uses macros consistently. * summary is OK. * description is OK. * dist tag is present. * build root is OK. * license field matches the actual license. * license is open source-compatible. * license text not included upstream. * latest version is being packaged. * BuildRequires are proper. * %clean is present. * package builds in mock (development, x86_64). * package installs properly * rpmlint has only acceptable complaints. X final provides seems to be missing something R-widgetTools = 1.12.0-5.fc8 = /bin/sh * %check is present but cannot be run without additional dependencies and can't be run in mock in any case. * owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * scriptlets are OK (R documentation index generation) * code, not content. ? documentation is a bit larger than the actual code. It might be worth splitting. * %docs are not necessary for the proper functioning of the package.
> I'm confused by the dependencies. This pachage seems to have no requirements > besides /bin/sh needed to run the scriptlets. Shouldn't it depend on R as well > as tcl and tk? It should. R-widgetTools makes R able to build tcltk widgets (tell me if i'm wrong). Also, the scriptlets action need index.txt which owned by R. However, tcl and tk packages no need to be added as Requires, they are already require by R package. = additional comment = Installing R-WidgetTools under x86_64 arch make the scriptlets fails to work. Cause %{_libdir} is defined as /usr/lib instead of /usr/lib64 due to noarch package set for R-widgetTools. > The final package is mostly documentation. The whole package isn't huge so I > don't think it's mandatory that it be split into a -doc subpackage and I know > that R has its own internal documentation browser system, but I still have to > wonder if the documentation in this package shouldn't be marked as %doc so a > smaller --excludedocs installation is possible. The question is simple: does > the package still work if you delete all of the documentation files. If so, > those files should all be marked as %doc. Remove docs files don't affect the use of R and R-widgetTools. It's just that if you invoke an htlm doc from R prompt, it will fails to find it/them (from htlm browser or online-help). So, i think that we can think about slip them into a -doc subpackage. * move them to %doc will make them out to work. But, if you really want them here, you will have to change all path which are in CONTENT file to point them to %{_docdir}/%{name}-%{version}/html instead of ../../../library/widgetTools/html As you can see, it go back 3 level down and then move to widgetTools/htlm.
I didn't say to move the documentation to %_docdir, I said mark them as %doc. I see no reason why they can't stay where they're located, and there's no need for amy symlink nonsense.
ho yeah, you right Jason i confused with both, sorry, french mistake
There is indeed a way do build the package without the documentation (If we add the --no-doc flag in the R CMD INSTALL command). I have tested it and the html interface do not show the link to the documentation of this library any more... I think that I get your point on we should give an opportunity to the user to not set up the doc as the normal R CMD INSTALL give. (I have to sort out how to do it now ;-) ) === Question : I am surprise by this: Jason wrote: package builds in mock (development, x86_64). Xavier wrote: Installing R-WidgetTools under x86_64 arch make the scriptlets fails to work Is it normal ? In the case that Xavier is true, is there a way to avoid it ?? thanks ~P.
Didn't suggest building the package without the documentation. I only suggested marking it as %doc in the %files list so that an end user could opt to install the package without it by passing --excludedocs to rpm.
I have mark the files in /R/library/%{packname} as %doc (I have to remove then to %files) I went back to the previous situation, I do not used the --no-docs any more on the set up. SPEC : http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools.spec SRPM : http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools-1.12.0-6.fc6.src.rpm Thanks :-)
I discovered by testing the package that I made some mistakes on the files (I had lost the html interface) There is a corrected version who is working: SPEC: http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools.spec SRPM: http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools-1.12.0-7.fc6.src.rpm Thanks
OK, now we're getting somewhere. Here are the remaining issues that I see: This packager is still missing a dependency on R. You should own the directory /usr/share/R/library/widgetTools. The easiest way to do this without recursively pulling in everything below is to have %dir %{_datadir}/R/library/%{packname} in your %files section. I think the latex directory is documentation as well. These are all minor. However, here's a tough one: The reference to %{_libdir} in %post means that this isn't actually a noarch package. I built it in x86_64 rawhide, and being noarch it should install fine on i386 rawhide, but it doesn't: /var/tmp/rpm-tmp.97210: line 1: /usr/lib64/R/doc/html/search/index.txt: No such file or directory error: %post(R-widgetTools-1.12.0-7.fc8.noarch) scriptlet failed, exit status 1 This is bad; either you need to figure out the directory at runtime or this can't be a noarch package. And ignoring that, don't your scriptlets as is ignore the arch-specific R modules that might be installed by looking only in _datadir? I'm beginning to wonder whether it's at all worth it to have noarch R packages. I know this is tougher than it needs to be because we have no R packaging guidelines and I'm just sort of guessing as to what R actually needs.
Ok I have tried to do a full noarch rpm there are the results: SPEC: http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools.spec SRPM: http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools-1.12.0-8.fc6.src.rpm Let me know... :-)
I have justed made some tests, If you remove the package that is the only one in /usr/share the scriplet %postun failed (of course as he does not find the file CONTENT) So I have made some changes and now it seems to work better SPEC: http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools.spec SRPM: http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools-1.12.0-9.fc6.src.rpm :-)
OK, this builds fine on x86_64 and the built package installs/uninstalls properly on i386. rpmlint has sprouted a new warning: W: R-widgetTools dangerous-command-in-%postun rm which is correct, rm is dangerous and it's used in %postun. Honestly at this point I don't know enough about R to comment on the post section; I'll try and get spot look over it. This is still missing a dependency on R. What's in %{_datadir}/R/library/%{packname}/man? It looks like manpages. Are these supposed to be accessible via man? Because the one in this package (widgetTools.Rd) isn't. If it's for some internal documentation browser then that would be OK (although in either case it should be marked %doc like the rest of the documentation). Anyway, this is very nearly done. Why don't you go ahead and apply for sponsorship so that I can take care of that in anticipation of getting this package imported.
The base R package has now been updated, and to boot there are complete specfile templates for R subpackages in http://fedoraproject.org/wiki/PackagingDrafts/R which are nice and simple. Of course, you can only build for rawhide at the moment, but my understanding is that spot intends to push the updated R package to at least F7.
As the new version of R has been released, There is the new spec and srpm resepcting the R packaging guideslines: SPEC: http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools.spec SRPM: http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools-1.12.0-10.fc6.src.rpm I have tested it when it is the only package installed in %{_datadir} there is no warning any more. Regards
However it seems that there is still a problem: $ mock ../SRPMS/R-widgetTools-1.12.0-10.fc6.src.rpm init clean prep This may take a while unpack cache setup No srpm created from specfile from srpm: R-widgetTools-1.12.0-10.fc6.src.rpm ending done I have tried with 3 different RPMs and I have always the same error... whereas the rpmbuild and rpmlint give none...
See root.log in /var/lib/mock/fedora-[version]-[arch]/result
The R packaging guidelines have been updated after the comment that I made based on this error and after the meeting so there are the new version : I think this package will be the last release :-) SPEC: http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools.spec SRPM: http://pingoured.dyndns.org/public/RPM/R-widgetTools/R-widgetTools-1.12.0-11.fc6.src.rpm Thank for your help
Actually we're in a packaging committee meeting now. I'll take a look when that's done.
OK, it looks like you're using the latest version of the template, so that's good. There is one pending change to the noarch template which you will need to add as well, which is a runtime dependency on R: Requires: R rpmlint does have some complaints, but they are both bogus and explained in the guidelines: W: R-widgetTools one-line-command-in-%post /usr/lib/rpm/R-make-search-index.sh W: R-widgetTools one-line-command-in-%postun /usr/lib/rpm/R-make-search-index.sh Really, that's about it, so I'll trust you to add that dependency when you check in. APPROVED
New Package CVS Request ======================= Package Name: R-widgetTools Short Description: Tools to support the construction of tcltk widgets Owners: pingoufc4 Branches: FC-6 InitialCC:
Do you really only want a FC-6 (and devel) branch here? Any reason not to also support F-7?
Well my computer is still under FC6... Can I ask for a F7 branch without being able to test the package on my computer ? If I can ask for the F7 branch, then I do :-) Thanks
It's ok to ask for a branch without being able to test, except if you have reason to think that it wont work.
Then :-)... New Package CVS Request ======================= Package Name: R-widgetTools Short Description: Tools to support the construction of tcltk widgets Owners: pingoufc4 Branches: FC-6 F-7 InitialCC:
cvs done.
R-widgetTools-1.12.0-12.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
R-widgetTools-1.12.0-12.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.