Tom Moertel wrote:

Let's divide up the prerequisites and package 'em. I'd like to claim plyr because I have a need for that package on its own.

I packaged plyr tonight:

http://community.moertel.com/rpms/fedora/10/SPECS/R-plyr.spec http://community.moertel.com/rpms/fedora/10/SRPMS/R-plyr-0.1.9-1.fc10.src.rp...

I had to disable the %check because it tried to do some Tk stuff that required a valid DISPLAY. The Tk stuff does appear to work, however, once the package is installed.

If anybody would give the package a quick review, I'd appreciate it. Tomorrow or the next day, I'll submit R-plyr as a new package unless there are any objections.

Cheers, Tom

On Tue, 2009-09-01 at 22:46 -0400, Jack Tanner wrote:

Tom Moertel wrote:

...

I packaged plyr tonight:

http://community.moertel.com/rpms/fedora/10/SPECS/R-plyr.spec

Thanks for taking a stab at plyr. I'm a very inexperienced packager, but these are the questions that I'd be asking if I were a reviewer.

• Do you need to worry about the requires (R-RUnit R-abind R-tcltk)?

Two out of three are already done and in the repo R-tcltk will have to be done.

• It seems wrong to hard-code Source0 rather than making it conditional

on the variables defined in the spec. See my RMySQL spec (which could be totally goofy, and I've had no feedback on it) here: https://www.redhat.com/archives/fedora-r-devel-list/2009-August/msg00007.htm...

The Source0 is not wrong, changing it to use the macro make just the maintenance of the package easier (you won't have to change the Source0)

• Since plyr is noarch, you could remove the commented-out arch-specific

stuff.

+1 to clean the spec You have also the: - change the BR tetex-latex to tex(latex)

Regards,

Pierre

Pierre-Yves wrote:

...

R-tcltk will have to be done.

In fact R-tcltk does not exist, the spec should be corrected. The Requires is on tcltk itself.

R-tcltk does exist; it's provided by R-core:

$ rpm -q --whatprovides R-tcltk R-core-2.9.2-1.fc10.x86_64

And R-core is what requires tk:

$ rpm -q --requires R-core | fgrep tk libtk8.5.so()(64bit)

So, should I leave in the requirement (in case, for example, the R-tcltk bindings are later moved into a separate package), or should I remove the requirement under the assumption that R-tcltk will always be provided by R-core?

Cheers, Tom

Tom "spot" Callaway wrote:

I think it is safer to depend on R-tcltk. [...]

I'll leave the R-tcltk requirement in, then.

With that in mind, here's take 2:

http://community.moertel.com/rpms/fedora/10/SPECS/R-plyr.spec http://community.moertel.com/rpms/fedora/10/SRPMS/R-plyr-0.1.9-2.fc10.src.rp...

Cheers, Tom

Pierre-Yves wrote:

...

Did you look at the subdependencies ? I mean that for example quantreg requires SparseM tripack, akima, MASS, survival, rgl, logspline (Which already points out a circular dependency on MASS)...

I did not look at the subdependencies. Whoops. Thanks for pointing that out.

Might be worth to have a look at what R P Herrold did since *he* packaged most of the cran.

I found this: http://article.gmane.org/gmane.comp.lang.r.fedora/17 , which is very informative, but doesn't link to the SPECs or SRPMs for any of those things he packaged up. There's nothing at his FTP site either, ftp://ftp.owlriver.com/pub/local/ORC/R/ . Is there another source?

Thanks for finding this. I passed this message on to the CRAN maintainers (CRAN also distributes binaries for Windows and Mac OS X) who also contacted the SparseM package author.

Martyn

On Wed, 2009-09-02 at 11:03 -0400, Tom "spot" Callaway wrote:

On 08/28/2009 10:10 PM, Jack Tanner wrote:

...

quantreg http://cran.r-project.org/web/packages/quantreg/index.html

I took a shot at this one (and its depends/suggests), and I ran into SparseM. It claims to be GPL on its CRAN page, but that is not entirely true, as its LICENSE file admits:

== LICENSE ==

All R code and documentation in this package is licensed under the terms of the GPL license -- see COPYING in the top level of the R directory tree for further details.

All fortran and C code in the src directory, with the exception of cholesky.f is also licensed on the GPL license, see

    http://www.cs.umn.edu/Research/arpa/SPARSKIT/sparskit.html

for explicit stipulation for sparskit.f. The code in cholesky.f is a modified version of code originally written by Esmond Ng and Barry Peyton. The modified version is distributed as part of PCx by Czyzyk, Mehrotra, Wagner, and Wright and is copywrite by the University of Chicago. The PCx distribution makes the following stipulation:

    This software discloses material protectable under copyright
    laws of the United States. Permission is hereby granted to use,
    reproduce, prepare derivative works, and redistribute to others
    at no charge, provided that the original PCx copyright notice,
    Government license and disclaimer are retained and any changes
    are clearly documented; however, any entity desiring permission
    to use this software within a commercial organization or to
    incorporate this software or a work based on the software into
    a product for sale must contact Paul Betten at the Industrial
    Technology Development Center, Argonne National Laboratory.

            PAUL BETTEN
            betten@anl.gov
            Industrial Technology Development Center,
            Argonne National Laboratory,
            Argonne, IL 60439
            (630) 252-4962
            FAX: (630) 252-5230

== EOF ==

That PCx license from ANL is non-free, due to its commercial use restriction clause. That license is also incompatible with the GPL, so the entire work is almost certainly not redistributable when compiled together.

In order to include this package in Fedora, we would need to get permission from Paul Betten to use that file under a GPL compatible license (or the GPL itself). I have sent an email to Mr. Betten, and I am hopeful that he is still at ANL, and that he is willing/able to resolve this licensing issue.

~spot

---

Fedora-r-devel-list mailing list Fedora-r-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-r-devel-list

----------------------------------------------------------------------- This message and its attachments are strictly confidential. If you are not the intended recipient of this message, please immediately notify the sender and delete it. Since its integrity cannot be guaranteed, its content cannot involve the sender's responsibility. Any misuse, any disclosure or publication of its content, either whole or partial, is prohibited, exception made of formally approved use -----------------------------------------------------------------------