Re: packaging stan
Hi,
On Sat, Aug 03, 2013 at 12:50:53PM -0700, Ross Boylan wrote:
> On Sat, Aug 3, 2013 at 9:05 AM, Andreas Tille <andreas@an3as.eu> 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 their license is DFSG-compliant then you can leave them in if you
want. But you should/must modify the build system to use the respective
Debian packages instead of the locally shipped ones.
You can also strip them out if you prefer (this is required for non-free
stuff).
> 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.
Right. The usual way is to prepare an upstream tarball which is
stripped off the offending files. I am not sure what the best practise
for git is here as I do not heavily use it myself.
You can use a patch system to change the build system to bypass those
included sources, though.
> > > 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.
It sounds like rstan is an R wrapper around stan? Then I would assume
it should be possible to build/use rstan without the full stan source
being around.
Is stan building a shared or static library? If not, that may be the
missing link between the two. Requiring the stan source be present when
building rstan (as a seperate source package) will not work or only work
with lots of trouble I do not think is worth it. So if there is no
library being built or other support, combining both into one source
package might be an option.
One indication this is alright would be that both stan and rstan are
released in lockstep.
Michael
Reply to: