Red Hat Bugzilla – Bug 241082
Review Request: R-tkWidgets-1.14.0 - Widgets to provide user interfaces
Last modified: 2007-12-04 17:56:52 EST
Spec URL: http://pingoured.dyndns.org/public/RPM/R-tkWidgets/R-tkWidgets.spec
SRPM URL: http://pingoured.dyndns.org/public/RPM/R-tkWidgets/R-tkWidgets-1.14.0-2.fc6.src.rpm
Widgets to provide user interfaces. tcltk should have been installed for the
widgets to run.
Based on the R packaging guidelines
There are the new files:
Looks like this depends on R-DynDoc.
Went ahead and knocked DynDoc out and stuck it in a local repo so I can review this.
The License: tag needs a tweak for the new scheme. Unfortunately, I can't
figure out what it might be; there's no actual mention of the LGPL in the
tarball apart from the DESCRIPTION file which just says "License: LGPL". The
code itself has unpleasant "All rights reserved" copyright notices.
I think you will need to ping upstream and see if they can clarify.
I note ths doesn't build without R-DynDoc, but does it have any runtime
requirements on it? Similarly for R-widgetTools and the tcl/tk stuff.
Currently you can install this with only R being present on the system, but I
don't know if it will actually work.
* source files match upstream:
* 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 is sufficiently silent.
X final provides and requires are missing some dependencies:
R-tkWidgets = 1.14.0-4.fc8
* %check is present but I'm not sure there are any tests to run.
* 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 module registration)
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
I will send him an email about this question.
Would you like to be add in Cc ?
You can CC me if you wish, or just note the results in this ticket. Either way
works for me.
>I note ths doesn't build without R-DynDoc, but does it have any runtime
>requirements on it? Similarly for R-widgetTools and the tcl/tk stuff.
>Currently you can install this with only R being present on the system, but I
>don't know if it will actually work.
R libraries call functions that are included in other libraries, I believe this
is the reason why they are depending on each other.
The tcl/tk interfaces is also used for example when you have two time the same
function (different functions but with the same name) on different packages, and
you ask for the help file of the function, it loads then an interface where you
can choice which help you want to consult.
To check whether the package work you can first run R and load the library using
library() => list all libraries installed
library(tkWidgets) => load this library
You can also find there some example implement for this library
I have mailed the maintainer of this package, he is now out of office, but do
not precise when he will be back
> R libraries call functions that are included in other libraries, I believe
> this is the reason why they are depending on each other.
Yes, I understand that, but my complaint is precisely that this package, when
built, does not depend on any other R packages. You have them as BuildRequires:
but not Requires:, and rpm will not figure out R dependencies automatically as
it will for Perl packages.
> You have them as BuildRequires but not Requires
My mistakes, I forgot to add them at their place...
There is the new SPEC and SRPM, however I still have no answer from either the
maintainer of this package or the one of maanova...
I have kept the license as LGPL for now..
I just received the answer from the developer.
He said :
"The license of the whole package is LGPL. If part of the code is used outside of
the package, I need to be contacted.
Hope this helps."
Well, that's not very specific as to things like the version of the LGPL. I
guess we can say LGPL+ to allow any version, but please also include your
correspondence with the author as a text file in the package.
With those changes I believe I'd approve this package, but I'm trying to make
sure and can't seem reach www.pingoured.fr to get the updated spec.
Sorry for the inconvenience the server has been deplaced and I have tried to
have it working yesterday but could not manage to do it.
I will contact you on irc once it is back.
You can put it on your fedorapeople.org page, mail it to me or just attach the
spec here if you like.
Server is back and the new rpm to :)
I talked to spot and he indicated that what I wrote above is incorrect; we
should not just assume LGPL+ unless we have no other choice. So since the
author is responding, we need to ask him what version of the LGPL this package
it seems that my server has some trouble..
These address should be working:
I will send a new email to the author about the version of the LGPL used here.
I just received the answer
> Could yo tell me which version of the LGPL license is used for this
> >library ?
Most BioC libraries are going to be licensed under "The Artistic License,
Verison 2.0". I am going to change the license to that soon."
Should we changed it now ?
This is like some kind of bad joke.
I honestly don't know if we can change the license tag now, without some
statement from the author that he has relicensed the current version.
Either wait for him to make a new release under Artistic 2.0, or use "LGPLv2+"
until he releases a new version.
I would go for the second solution and wait the new release to change the
To change the license tag I "just" have to make a new release, isn't it ? (and
as I actually package only the "stable" libraries from bioconductor, the new
release will be in some months)
The new file has been uploaded:
There are the new
Looks good. The dependency list is now:
R-tkWidgets = 1.16.0-1.fc8
The sources still match upstream:
And the license, well, Artistic 2.0 is OK. It would sure be nice if these folks
paid attention to just the basics about how to put license statements in their
code and such, but at least we have enough now to go on.
Pierre-Yves: this looks like it's been approved, can you build this now, it's
needed for reviewing: bug #240500.
New Package CVS Request
Package Name: R-tkWidgets
Short Description: Widgets to provide user interfaces
Branches: F-7, F-8
Cvsextras Commits: yes
Please use your Fedora Account System login for Owners...
There's a problem with this package, because it installs into
/usr/share/R/library/ rather than /usr/lib/R/library/ R can't find the package
at run-time (this also applies to R-widgetTools and R-DynDoc). I know this is
the case, because if I create symlinks like so:
ln -s /usr/share/R/library/tkWidgets/ /usr/lib/R/library/tkWidgets
everything works, so it appears that something isn't being set by the install
that tells R to also look in /usr/share/R/library/
e.g. here's how to reproduce this:
Error in library(tkWidgets) : there is no package called 'tkWidgets'
Loading required package: widgetTools
Loading required package: tcltk
Loading Tcl/Tk interface ... done
Loading required package: DynDoc
Loading required package: tools
$ rpm -q R-tkWidgets
$ rpm -q R
Seems to work fine for me...
ok, was a problem with me setting R_LIBS in ~/.Renviron. Setting this should
not override any of the system locations, however. Will file another bug about
this later since this is not a problem with this particular package.