Re: R packages

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

Benny,

Thanks for your input.

Benny Siegert writes:
 > I did something like this a few years ago for MirPorts: a tool that
 > can create perl module packages from information extracted with the
 > CPAN module, including, yes, a recursive mode.
 > 
 > I promised to port it to pkgsrc but I have not found the time yet. See
 > http://www.slideshare.net/bsiegert/painless-perl-ports-with-cpan2port

Yes, I recall.  I am eagerly awaiting the port to pkgsrc, because
there is a large group of perl packages (namely bioperl) that really
need to get into pkgsrc.  Without a tool like this, the task is
_really_ tedious and hence has never been done.  However, that is
holding up some important capability being included within pkgsrc.
Nudge, nudge. :)

 > Or you could make the tool interactive and ask the user for the
 > category (which is what cpan2port did).

I kind of agree with Greg about noninteractive tools, but will perhaps
reassess this later.  Suggestions on how to handle non-interactively
and conveniently distinct categories for different packages within a
single run of the tool are welcome.

 > This is actually extremely easy. If your package is called R-foo (for
 > example), then doing
 > 
 > cd /usr/pkgsrc ; ls */R-foo

It's actually not quite that simple, although the public pkgsrc
repository might not indicate the counterexamples yet.  There are for
example large collections of R packages that are independent of CRAN
and would have a disinct pattern of Makefile factoring were they to be
imported into pkgsrc.  Bioconductor is one such example.  Thus, it
makes sense to consider the contents of the Makefiles in addition to
the names.

Nevertheless, the issue is moot as my current version of the tool
handles all of this just fine.  It will discover R packages using the
criteria of (i) the name (i.e., R-*) and (ii) the inclusion of
R/Makefile.extension regardless of where within the pkgsrc tree they
are.

Cheers,
Brook