[Debian-med-packaging] We need a global decision about R data in binary format, and stick to it.
Paul Tagliamonte
paultag at debian.org
Mon Aug 5 13:40:56 UTC 2013
On Mon, Aug 05, 2013 at 02:13:15PM +0100, Ian Jackson wrote:
> We need to separate these two issues.
Aye.
IMVHO, this is the same as how we should treat images (I mean, for any
data format, not just this one case of a pickled object) - if the image
was a photo, clearly the .jpg or .png or whatever we get is the best way
to communicate this data, but if the image was generated off an .svg,
it should be distributed with it (and even rebuilt at build-time).
> One is the file format question. It doesn't seem to me that there is
> anything wrong with a binary format as the preferred form for
> modification, in principle. For a file which is typically edited
> using R, including by upstream when they what to edit it, then there
> is no problem.
Sure. If this data wasn't collected off some scientific
instrument or lovingly hand-made, I strongly believe that we should
rebuild such objects at build time, and use those in the binary
packages.
> The other is the assertion that this particular case involves a
> generated data table. If this is the case then the source package
> needs to contain the source code which generates the table - and,
> really, it should regenerate the table during the build. (The source
> might be in the form of another R binary object.)
I completely agree.
> (Of course there is a third issue: it is probably not the best
> engineering decision to use a binary save format rather than text
> source code. But that's not something the Debian maintainer
> necessarily gets to choose and it's not a reason for an ftpmaster
> reject.)
>
> > > The question asked by Paul is a recurrent question that comes each
> > > time the FTP trainees rotate (basically once per release cycle,
> > > because during the Freeze the FTP trainees find other exciting
> > > tasks to do, and then do not seem to have much time to process NEW
> > > anymore).
> >
> > This must mean many people who care deeply about this topic see this as an
> > issue.
>
> I don't think this is a helpful response to someone who is raising
> what they see as a systematic problem.
I'm sorry, Charles. Ian's right. That was a poor tone.
>
> Paul, would it be possible to update the ftpmaster assistant reference
> materials to discuss R's binary files ?
I would be happy to document what is and isn't OK with these files. I'll
have to seek a bit of consensus from the rest of the ftp-team, but I
think treating them as if they were any other data format should be
fine.
>
> Ian.
Thanks, Ian,
Paul
--
.''`. Paul Tagliamonte <paultag at debian.org>
: :' : Proud Debian Developer
`. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87
`- http://people.debian.org/~paultag
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20130805/0f53aff4/attachment.sig>
More information about the Debian-med-packaging
mailing list