On Mon, Jul 2, 2012 at 9:16 AM, David A Case <case.biomaps.rutgers.edu>wrote:
> On Mon, Jul 02, 2012, Jason Swails wrote:
> >
> > My argument was simply that if we release a tarball with a modified
> > configure, then people would have two different configure scripts
> depending
> > on when they downloaded AmberTools.
>
> But I was assuming that a bugfix updating configure would also be prepared.
> That seems to be implied by your statement as well: how else would people
> who
> got the original AmberTools tarball get the updated configure script?
>
If a bugfix updating configure was also prepared, we would have to prevent
users downloading the 'new' AmberTools from applying that patch (since they
would already have that change applied, so the patch would fail). That
would require modifying patch_amber.py in the new tarball to prevent those
users from trying to apply the unnecessary fix. Given this choice, I think
it's better to maintain slightly different configures than more divergent
patch_amber.py scripts.
There's an --ignore-fails mechanism that users (or configure) could employ
if they know to expect and ignore this issue, but I think this is worth
avoiding too.
By releasing bugfix.13 (12 just came out) to fix configure to the current
git version and then releasing AmberTools 12.13, we ensure that everybody
that downloads the new AmberTools has the 'fixed' patching process, remains
identical to everyone else that downloaded it before (as long as
--patch-level is the same), and the patches that are built into the tarball
are already registered as applied patches. The downside of an
AmberTools12.13.tar.bz2 is that users may mistakenly think they need to
upgrade when they don't (could we just package it up as
AmberTools12.tar.bz2 with 13 silent patches inside? --patch-level will
never lie, in any case, and is probably still the preferred method of
determining whether users applied a fix or not).
Thanks!
Jason
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Jul 02 2012 - 07:00:02 PDT
