On Mon, 05 Aug 2013, Ian Jackson wrote: > 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 know of almost no cases where someone actually generated the R binary object directly. In general, you have a data table represented as some kind of text file, and then you do operations on it, which result in a R binary object being created from a collection of text files. Subsequently, you might load the R binary object and modify it within R, but for some modifications, you might want to go back to the original data table. It's unfortunately common practice for R upstreams to ship the binary object instead of the combination of original tables and R source necessary to generate the actual R binary save data, but this is something that should be changed, and Debian should be working to lead the charge to do this. In almost all cases, dropping the R binary object(s) do not appreciably change the functionality of the R module; it just means that it is more difficult to use the examples because there is no example data. -- Don Armstrong http://www.donarmstrong.com in Just- spring when the world is mud- luscious the little lame baloonman whistles far and wee -- e.e. cummings "[in Just-]" -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130805224955.gd14...@rzlab.ucr.edu
