[Debichem-devel] jgromacs package seems useful

["Steffen Möller"]

-------- Original-Nachricht --------
> Datum: Thu, 17 May 2012 14:22:25 +0200
> Von: Michael Banck <mbanck at debian.org>
> An: debichem-devel at lists.alioth.debian.org
> Betreff: Re: [Debichem-devel] jgromacs package seems useful

> On Thu, May 17, 2012 at 02:11:49PM +0200, Daniel Leidert wrote:
> > Am Donnerstag, den 17.05.2012, 13:08 +0200 schrieb "Steffen Möller":
> > 
> > [..]
> > > > > One thing about README.source; I think if you do something fancy
> with
> > > > > the original tarball, it would be best to supply a
> "get-orig-source"
> > > > > script for the modifications.
> > > 
> > > Right. This is why I had time to address the packaging and you had not
> :o)
> > [..]
> > > > > I take you based you packaging on "jgromacs_v1_src.tgz"?
> > > 
> > > Yes.
> > > 
> > > > > I just renamed the "source" directory inside the jgromacs tarball
> to
> > > > > "jgromacs-1.0" here so far, and it build fine.  
> > > > > 
> > > > > You wrote you removed jama, I think it is fine to keep it even if
> it is
> > > > > not used in the build.  Unless we have to remove it due to some
> > > > > licensing issues, which I guess is not the case?
> > > 
> > > Hm. The debian/copyright file would need to be amended. IIRC correctly
> > > then my build instructions only take code from the jgromacs subfolder,
> > > i.e. the extra eyeballs on the Jama library remain established. That
> > > is the only bit that is important to me, really. Leave it in if you
> > > prefer, even though I had done that fancy GZIP=-9n while retaring.
> > 
> > Hi guys. I added a script to create the tarball and made some other
> > changes, which I thought should be done.
> 
> I haven't tried it (not least because I can never remember how to run
> debian/watch and/or debian/get-orig-source.sh properly), but you're
> removing the jama directory while I don't see a +dfsg in the version.

It is not because of license incompatibilities but more because of the technical beauty. We also remove .jar files and other bits that we do not want to give the impression of being used. Same here.
 
> Granted, the removal was not due to DFSG issues, but shouldn't there be
> some other indication that this is not the prestine source other than in
> README.source?
> 
> I still think repackaging the upstream source just because parts of it
> are unused (and this is not a huge space problem, i.e. > 10 MB or so) is
> unnecessary.

Adding a +dfsg sounds right to me. An email to the authors is also not unlikely to get that jama subdir removed in some future version.

Let us not talk too much about it. It is nicer without dead code, +dfsg is fine, the work is done and automated, necessary or not.

I had OpenMM to work as a package for me. Too say something more positive here. Coming.

Cheers,

Steffen