[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: best policies for third party Debian packaging and get-orig-source target




Hi Charles,

Thank you for your nice reply.

On Fri, 9 Aug 2013, Charles Plessy wrote:

Le Fri, Aug 09, 2013 at 03:00:25AM +0530, Faheem Mitha a écrit :

r-cran-scales is now in Debian, but r-cran-ggplot2 has not yet been
updated. I see that r-cran-scales is not installable, because it
depends on r-cran-munsell, which is not in Debian, at least not
currently on my mirror for amd64.

Hi Faheem,

r-cran-munsell was submitted to the Debian archive and is currently under
review.

   http://ftp-master.debian.org/new/r-cran-munsell_0.4-1.html

However, it contains a binary file, 'sysdata.rda', that is data table in a
compressed format.  The question is whether it is generated and refreshed by
the upstream author using a source file that is not distributed in the source
package.  Such a work would not be Free according to our principles.

   http://lists.alioth.debian.org/pipermail/debian-med-packaging/2013-August/021177.html

In the newer upstream version 0.4.2, there is a script to generate sysdata.rda
from another file, real.dat, in text format.  There is no information on where
this table comes from, how was it created, and what is the preferred way to
modify it.

I see the text file real.dat.

If you had time to contact the upstream authors and get this point clarified,
that would be a tremendous help.  In the meantime, it may be difficult to
update r-cran-ggplot2.  I have asked for a temporary exemption, but I did not
receive an answer yet.

   20130807233230.GA12437@falafel.plessy.net">http://lists.debian.org/20130807233230.GA12437@falafel.plessy.net

So, you want to know where the table comes from, how it was created,
and what the preferred way to modify it is?

My guess is that it is just data collected from somewhere. But sure, I
can send a message to get the ball rolling, if the Debian FTPmasters
are not satisfied.

Have a nice day,

PS: I had a quick look at corrmodel (but did not have time to test
it), and did not find obvious problems.  For the package containing
the R scripts, it may not be necessary to name it according to the
convention for packaged R modules, since it is not a R module.  By
the way, is it a software to study clonotypes ?  I have a (much
simpler) work on line at http://clonotyper.branchable.com/

I'm not familiar with the term clonotype, but certainly this is
similar.  All I'm trying to do is model a collection of Recombination
Signal Sequences (RSS) in order to do prediction on them using
Bayesian methods. I'll send you a copy of my current draft in case you
are interested. Comments, corrections, questions etc. are all most
welcome. Also, if anyone else is interested, I can send it to them.  I
just don't want to send it direct to a mailing list.

What would you suggest I call the package containing the R scripts?
What about corrmodel-r-scripts?

As far as testing the package goes, it is quite complicated and
computation-intensive, so don't worry about it, unless you are really
interested. The current instructions in the code are quite broken and
useless, but I will update them soon. I'm planning to include
instructions in the code to reproduce the figures from the paper, but
I'm not there yet.

                                                       Regards, Faheem

Reply to: