Thanks for the quick response.
On Sat, Aug 3, 2013 at 9:05 AM, Andreas Tille <[email protected]> wrote: > Hi Ross > > On Sat, Aug 03, 2013 at 08:06:16AM -0700, Ross Boylan wrote: > > I am thinking of packaging stan and rstan, and would appreciate some > advice. > > Nice. > > > stan is a program for doing Bayesian analysis with a variant of > > hybrid/Hamiltonian monte carlo. http://mc-stan.org/ homepage; > https://github.com/stan-dev/rstan.git > > and https://github.com/stan-dev/stan.git for code. > > > > It looks to me as if there are substantial parts of the source that > > should not be in the debian source; > > > http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-origtargz > > indicates this is possible, but not generally advisable. I'd > > appreciate feedback on how to handle this both in policy terms--what > > if any parts should I omit, and practical terms--best mechanics of > > doing this with an upstream git. Most of the other packaging > > documentation I've reviewed is silent on this topic (except for > > mentioning some git-specific helpers). > > Without inspecting the source in detail myself I'm not fully sure what > you might mean with the paragraph above but I will try to answer the > issues below. > Let me try again, with the issue you didn't discuss. The source package includes the source to external libraries. I am thinking of deleting them from the Debian source. Is that a good idea? If it is a good idea, what's the best way to do it? As I understand the patch system, it is not the right thing to use, since it applies packages to the source tarball, whereas I want to create a tarball without the files. Maybe I should create a debian directory and put a little script in there does an appropriate git rm. Or just do the git rm and let git remember. > > > In particular, stan includes a lib directory of external libraries. > > I assume a debian package should use already packaged versions of > > those libraries. > > Yes. This is what we put some effort into. It is very advisable for > several good reasons. > > > I'm assuming stan has not locally modified the > > libraries. > > It is most probably a good idea to ask the upstream authors about this. > They have just confirmed this, and indicated that their code is probably not too picky about the exact version one uses--although they really only "guarantee" that the versions they provide will work with their code. > > > Also, rstan includes stan as a subproject; I assume I would package > > the source would not. Though perhaps one source could be used to > > build stan and rstan. > > As I said I did not checked the source. If both programs might come in > one source it is possible to build two binary packages from one single > source package. There are a plenty of examples in our archive - just > ask if you need a more specific pointer. > This again raises a subtraction issue. I may want to provide Debian source for rstan that does not include stan. > > > The system itself is fairly complicated; stan works by translating a > > program into C++ and then compiling the program at run-time. Also, it > > includes a library as well as a front-end program. > > > > rstan an R package designed to call stan from R. It is set > > up so that one downloads the R package and, while installing it in R, > > the whole stan system gets built (so the R library source includes all > > of stan). > > > > The directory structure of rstan is a bit odd; the "real" R library > > source is in > > https://github.com/stan-dev/rstan/tree/develop/rstan/rstan, with the > > higher directories having meta-stuff (maybe the web page and tools for > > building the package including stan). > > Hmmm, I only know R packages from CRAN and the packaging is very simple > and straightforward. You can basically copy the stuf from another R > package and rename the basic things. Seems this is not the case here. > :-( > When I strip everything away I might end up with this situation. But the Debian package, presumably r-nocran-stan, will need to depend on stan, g++, and possibly other stuff. As a clue that stripping stuff from the source they provide is desirable, apparently the tarball they provide for the R package is too large to be hosted on cran. I think it's large because it includes all of stan, not just the R part. > > I'm not a debian developer, but I figured since I was interested in > > using the package I might as well try to package it. stan is not > > listed for wnpp. > > If you are no (not yet) a Debian developer that should be no problem. > In Debian Science team we have some tradition of inviting people who > are willing to work and we are propagating your work via so called > Sponsoring to the Debian mirrors. For Blends related packages (which > would fit here) I have a specific offer of "Sponsering of Blends"[1] > Excellent. Do I need access to, e.g., git repos on alioth? Upstream is on github, and I have an account there. > > Comments or suggestions welcome. > > Hope this helps for the moment. > > Kind regards > > Andreas. > > PS: Apropos Monte Carlo: Does anybody know > http://www.gel.usherbrooke.ca/casino/What.html > and is there any Free Software alternative? > > > It's unknown to me. Ross
