Hi Dave and Jason,
I'm not sure I follow here. I thought that patch_amber.py could 'detect'
that a patch was already applied by looking in the applied patches
directory. Thus my original suggestion which was to make a bugfix either for
configure 'or' ship AMBERTools with bugfix.3 already applied. If it is done
correctly then it should be automatically detected that the patch is already
applied should it not?
Indeed, why don't we just do the following:
1) create a new bugfix for configure and release it on the website - just
the changes needed for running patch_amber.py multiple times, don't update
anything else.
2) Apply all the other bugfixes for AMBERTools.
3) Make a tar file called AmberTools12.13.tar.bz2 (the .13 referring to the
13 bugfixes applied). Add this to the download section on the website and
link it to AmberTools12.tar.bz2 so we don't have to update the instructions.
This way anyone who downloads the original AmberTools12.tar.bz2 file and
applies bugfixes 1 to 13 should get exactly the same distribution as if they
download the new tar file.
Maybe we take the time to update the manual in the doc directory (and the
one on the website) with the errata while we are at it?
All the best
Ross
> -----Original Message-----
> From: David A Case [mailto:case.biomaps.rutgers.edu]
> Sent: Monday, July 02, 2012 5:38 AM
> To: AMBER Developers Mailing List
> Subject: Re: [AMBER-Developers] Having to run configure multiple times
>
> On Fri, Jun 29, 2012, Jason Swails wrote:
> >
> > Another idea is to package up and release a AmberTools 12.11 which
> has all
> > 11 patches applied and logged...
> >
> > This has the side-benefit of no divergence between different AT
> downloads
> > (i.e., everyone has the same thing still, whether by using
> patch_amber.py
> > the whole time or downloading the new tarball).
>
> But wouldn't the same thing be true if the modified tarball just had
> the
> updated configure script? I guess I'd rather that everyone have
> (almost) the
> same files from the tarball, than to have to start dealing with users
> that
> have different starting points.
>
> ...dave
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Jul 02 2012 - 09:00:02 PDT
