Re: R packages

[brook%biology.nmsu.edu@localhost (Brook Milligan)]

Thomas Klausner writes:
 > How many packages are we talking about, circa?

My count of the DESCRIPTION files on CRAN is 3346.

 > (What is R if not a statistics tool, in other words, math?)

I think technically R itself is best viewed as a language and/or
interpreter for a language.  It also is shipped with a small number of
core packages that are oriented towards statistics.  However, by no
means are all 3346 CRAN packages best throught of as "math".

 > You have to find out which of the bsd licenses it is and use the
 > appropriate one.

The problem with some of this is that upstream is using non-specific
names for their licenses.  All I am trying to do with the tool is
catch cases that are well-defined and define a LICENSE clause as
appropriate.  In other cases, I simply include a line like

# LICENSE= whatever description that upstream gives

Whoever is working with the package can then investigate further.
Note that I am really just trying to create a tool that will improve
consistency of the R packages and ease their maintenance, not
volunteering to build thousands of them.

 > I think fetch should definitely be the default.

Ok.

 > I have no particular opinion on --recurse. In your usage, have you
 > found to use it all the time?

The main reason for using --recurse is to actually create packages for
dependencies of the desired packages.  Unless this is done it will be
impossible to actually build the newly created or updated packages.
Consequently, I'm guessing the main reason for not using --recurse is
for testing or something, but I don't really have other use cases in
mind.

 > So if you run it twice, or two packages on the command line depend on
 > the same package, the original file will be lost?

First, each package is only handled once, regardless of how many times
it occurs on the command line or in the dependencies that are
discovered.  The goal is that for pre-existing packages that are
updated, the Makefile will be preserved except for the
COMMENT/R_PKGVER/DEPENDS lines, which are replaced with new
information.  If this does not happen correctly, I consider it a bug.
Thus, running it twice (or more) should have no different effect than
running it once.

 > (I wouldn't modify it if an ".orig" file already exists; but then we
 > need a way to remove the .orig files semiautomatically again, perhaps
 > "R2pkg --remove-orig" to be run when you are finished committing.

One solution is to just remove the .orig files unless something like
--keep-original-files is used.  For the time being I was keeping them
to make sure nothing untoward was happening during the processing.  In
the long run they should not be necessary.

 > >                        BSD : no corresponding pkgsrc license
 > > GNU General Public License : no corresponding pkgsrc license
 > >                        GPL : no corresponding pkgsrc license
 > 
 > I'd rather mention the possibilities (see above for BSD, "gnu-gpl-v2
 > or gnu-gpl-v3" for the other two).

The point of this table is to know when to substitute a known pkgsrc
license (e.g., gnu-gpl-v2) into a LICENSE clause and when to simply
use the original information in a #LICENSE clause.  I think it useful
to be able to see the substitution table, especially if someone
discovers that some upstream license description should be substituted
but isn't simply because I have not yet included it in the table.
Perhaps the text of the note can be improved to reflect that;
suggestions welcome.

 > >                  Unlimited : no corresponding pkgsrc license
 > 
 > What's that?

No idea.  I'm just reporting the text used by upstream to give some
examples.

Cheers,
Brook