On Wed, 30 Jul 2014, Andreas Tille wrote:
Hi Roger,
On Wed, Jul 30, 2014 at 09:36:22PM +0200, Roger Bivand wrote:
Hi Andreas,
This isn't a patch to my spdep/inst/README file.
No, it's not! :-)
I have no knowledge
of any debian/copyright file, and cannot take responsibility for
that
This was never intended - it was just for our ftpmasters because its
their responsibility to verify the copyright + license of each file we
want to upload. Sorry if this was confusing.
(I don't think installing from source is a problem for
non-OSX/Windows users; I do not use Debian systems, and do not know
anything about their packaging systems other than very bad
experiences with people with messed up GIS packages). If you want me
to patch anything, diff from spdep/inst/README on R-forge. In
particular:
Copyright: 2005 Yongwan Chun, Michael Tiefelsdorf and Roger Bivand
License: GPL-2+
looks very wrong.
Well, the line above this was
Files: R/SpatialFiltering.R
in front of the Copyright/License paragraph. We need to list all
explicite Copyright statement inside the code. I can not see in how far
this should be in conflict with your spdep/DESCRIPTION file.
Please understand that the by-file copyrights are not important in R
packages that I have written and maintain. The DESCRIPTION file is the
root definition. I'm not prepared to check every file in spdep (or other
packages) for copyright definitions, as for R purposes these are covered
globally. If Debian "need to list all explicit Copyright statement inside
the code", that is a policy choice that is non-conformant with R packaging
practice. The dates are almost all wrong, and the names are often wrong.
There are more details in the ChangeLog, but even they are not consistent.
Often changes are made based on user wishes on our mailing list without
clear attribution by person (idea by NN, code changes by me). Sometimes
there are comments, but not always.
R/SpatialFiltering.R was written by Chun, Tiefelsdorf and myself, and has
been modified by me since 2005.
The list of contributors is in spdep/DESCRIPTION
in R standard parsable form;
+Files: R/bptest.sarlm.R
+Copyright: 1998 Joseph O'Rourke <orou...@cs.smith.edu>
isn't the correct file - should be src/soigraph.c.
Uhhmmm, perhaps I misinterpretet your first answer. We have to
troublesome files. Would you please consider reading the original mail
here:
No.
http://lists.alioth.debian.org/pipermail/debian-science-maintainers/2014-July/026470.html
I'd be grateful if you'd run any (unneeded) copyright file by me
before proceeding.
I hope not to do any unneeded work. The Debian copyright file is
required for any Debian package and you can have a look here:
http://anonscm.debian.org/viewvc/debian-science/packages/R/r-cran-spdep/trunk/debian/copyright?view=markup
I'd be more than happy if you could clarify the open issues for the
two files
src/soigraph.c
This is the problematic file which I covered in my earlier reply.
R/bptest.sarlm.R
The code is from a GPL 2 | 3 R package (when copied only GPL2,
subsequently 2 | 3 (but not 2+, either 2 or 3, not any beyond 3 if they
ever emerge).
in a format like this.
No way. The Debian formats are no help to me in what I do. If you need
that format, you should create it.
If such a file is needed, it should only point to
the correct file within the R package (otherwise they will get out
of sync).
Since we are packaging more than R packages in Debian we can not drop
this general requirement and we need to stick to the given format. I
agree that keeping these files in sync is a bit troublesome but I have
no choice but providing such a file (which works for >500 R packages
in Debian).
As you can see, the "decision" of a "master" is of very little use
s/master/ftpmaster/ = the gate keeper of the Debian package pool.
to me, I'll humour your attempts if you do things right, but have no
need to see spdep distributed in this way - Debian users should IMO
always install R packages from source to avoid unintended
incompatibilities.
The rationale why I intend to package spdep is that we have a certain
set of R packages packaged for Debian for very good reasons and now it
turned out that spdep is used as a new dependency to run a test suite of
some other packages.
So this is a dependency problem generated by some other R package that
imports from or depends on spdep? That is, spatial data analysis is
tangential to your needs? That makes me even less inclined to help. Which
package? My guess is stargazer, so the easy solution is to tell stargazer
to de-list spdep (the model output from models fitted in spdep is totally
misunderstood and mangled by stargazer omitting the spatial coefficoents -
I told the stargazer maintainer about this long ago, and asked him to fix
it, which he didn't).
Unless you explain why I should spend any more time on this, it isn't
going anywhere, and you are wasting time on spdep. I don't see any
benefits for my (many) users.
Roger
To make sure we will not have any
incompatibilities we really want to run the test suite - thus I need to
provide a spdep Debian package. I'm aware that there are people who
consider Debian packages of R packages useless but as you probably also
know there are varying opinions about this and I'm just doing it as
a service request of some users (and not because I have no better clue
how to spend my spare time ;-)).
Best wishes,
Same to you and sorry for the confusion I might have created
Andreas.
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 91 00
e-mail: roger.biv...@nhh.no
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
