brook%biology.nmsu.edu@localhost (Brook Milligan) writes:
> I end up using a lot of R packages and tend to find that they are not
> yet in pkgsrc. Over the years I have either added them or created
> them privately, but that has become tedious enough that I have now
> written a tool to automatically create them (see the current version
> of the man page below). I would like to commit this as pkgtools/R2pkg
> at some point in the future. However, I would like to seek some
> consensus on how we wish to handle R packages into the future, because
> this tool will (I hope) make it easier to import and maintain R
> packages within pkgsrc so there may very well be _many_ new ones.
There are a lot of python packages, and a lot of perl packages, so that
seems ok.
Do you think it makes sense to have R2pkg, or to have a mk/r.mk that one
can set a few variables and include? In other words, do the packages
created with R2pkg have a lot of lines ripe for common subexpression
elimination?
Looking, it seems like it's:
.include "../../math/R/Makefile.extension"
which seems reasonable.
Of R-geoR/Makefile, I only see HOMEPAGE as something that could be ?= in
the common Makefile:
/usr/pkgsrc/math > egrep HOMEPAGE\|R_PKGNAME R*/Makefile
R-CGIwithR/Makefile:HOMEPAGE= ${R_HOMEPAGE_BASE}/CGIwithR/
R-CGIwithR/Makefile:R_PKGNAME= CGIwithR
R-DAAG/Makefile:HOMEPAGE= ${R_HOMEPAGE_BASE}/DAAG/
R-DAAG/Makefile:R_PKGNAME= DAAG
Which isn't a big deal. So if your script makes packages that look
like these, that seems entirely sensible.
> First, all R packages are currently under the "math" category. I
> propose creating a new category "R" and moving them all. This will
> better separate R packages (which are in fact not all math related)
> and will prevent overwhelming the legitimate math packages with more R
> packages.
I am generally opposed to renaming.
In this case, it would be like having a python category for all the
py-foo scripts, and then perl, ruby, etc.. I'd say each R-foo package
should go where it should go, in the existing categories.
> Second, I would appreciate help on license handling for R packages.
> Most R packages have an indication of the license that applies. I
> have built into the tool a map between those descriptions and the
> known licenses in pkgsrc. In some cases, however, the mapping is
> unclear. For example, how would "BSD" map given the several variants
> of the BSD license? And, how would "GPL (>= 2)" map? Please see the
> current set of known licenses below and offer any suggestions.
If it is not entirely clear what the actual text of the license is from
data in the upstream distribution, upstream is broken and you should
file a bug report. Someone who says "Permission granted to copy under
the BSD license." is being unclear.
As Thomas says, we denote "GPL Version 2 or later" as gnu-gpl-v2. "or
later" is perhaps very important to the project, so that it can change
to "GPL Version 3 or later" without needing to get permission from all
contributors (because it already had it). But the notion that there are
people out there that really object to *using* software under v2, and
are ok with v3, and want to encode this in their mk.conf, really seems
to be a bit hard to believe. So we just label v2-or-later as v2, and
don't worry about it - if you're ok with v2, you're (correctly) ok, and
if you aren't, IMHO that theoretical person, once real, can volunteer to
deal with this issue :-)
But, if you want to put in
# GNU GPL v2 or later
LICENSE= gnu-gpl-v2 OR gnu-gpl-v3
that seems entirely appropriate.
> Finally, as the command line arguments are currently set up, the
> normal case is to use both --fetch and --recurse. Should I make these
> the default cases and have corresponding --no-* options to turn them
> off?
--fetch seems like it should just be on; url2pkg works that way.
--recurse: I can see the point, but it seems like the right thing is to
default to off, and to fail with a list of the prereqs that are not
installed.
> ===========================================================================
> R license : pkgsrc license
> ------------------------------------------------------------
> Apache License 2.0 : apache-2.0
> BSD : no corresponding pkgsrc license
Confused; if they refuse to fix this would assume original-bsd, since
complying with that results in complying with modified-bsd.
> GNU General Public License : no corresponding pkgsrc license
This is confused -- does not name a license. Surely they don't mean
version 1.
> GPL : no corresponding pkgsrc license
as above.
> GPL (>= 2) : gnu-gpl-v2
> GPL-2 : gnu-gpl-v2
> GPL-2 | GPL-3 : gnu-gpl-v2 OR gnu-gpl-v3
> LGPL (>= 2) : gnu-lgpl-v2
> LGPL-2.1 : gnu-lgpl-v2.1
> MIT : mit
Confused; there is no such thing as an "MIT" license. MIT has used a
number of licenses, and usually when people say "MIT license" they mean
"X11 license".
> Unlimited : no corresponding pkgsrc license
Confused, with vigor.
> file LICENSE : no corresponding pkgsrc license
> ===========================================================================
So there perhaps one needs to maybe add a license, or (manually) wdiff
to find one that's textually equivalent.
Attachment:
pgpkCPQLKoDDf.pgp
Description: PGP signature