On Sat, Nov 5, 2011 at 1:42 AM, Ross Walker <ross.rosswalker.co.uk> wrote:
> Awesome idea... (can we call it yum? ;-) ).
>
yum? Like the RHEL package manager?
> I think the key will be thinking it out and planning it very carefully from
> the beginning though - and trying to make it generic enough that it keeps
> working as changes are made in the development tree. I.e. if new
> directories
> are created etc. It would be ideal if it did NOT need to be updated for
> such
> changes.
>
One of the primary design goals is that this script never changes (though
it can patch itself if it has a bug I didn't see). I had thought about
just having it apply bug fixes via patch, but will patch not create new
files and directories as needed? I thought one of Dan's cpptraj patches
did this... I could certainly parse the files to be modified from the patch
and create any that didn't already exist if that was necessary (but I think
we should try to avoid too much of this via patches, since those tend to be
feature enhancements rather than bug fixes).
A benefit of this approach is one of the issues that plagued one of Dan's
patches won't exist any more (the 3 lines of context weren't enough to
prevent multiple patches from "succeeding"), since no patch will even
attempt to be applied more than once.
In principal though I like the idea. Although maybe one could consider
> having it and option as part of configure?
>
Something else I hadn't thought of. I'll discuss this in a little detail
below.
rm -rf /,
Jason
Additional details for the interested:
The way I had thought of the implementation was just calling patch. The
main advantages of the script approach would be appropriate book-keeping,
automated checking, and automated application of patch files we upload. I
think it would be awfully difficult to generalize it to the point that it
could handle something like our bugfix.17 process for AmberTools 1.5 +
Amber11, but maybe there are better ways than using patch to actually apply
the changes (I'm hesitant to use git-apply, since not everyone may have
git)? One of the key details of the implementation would be that the patch
file itself would be parsed for details and information. That's what would
allow this script to remain general and unchanging. Of course, this
requires a fixed format for the bug fixes themselves, but that shouldn't be
hard since we already have a general format that I think we follow for the
most part, anyway (but now we'll have to enforce it). To aid in this,
maybe a script we dump into amber_web that checks any added bug fixes to
see if they're valid or not would be helpful? (As well as detailed
documentation for creating bug fixes). We don't want to upload bug fixes
that this script will choke on.
Another key design feature is allowing apply_bugfix.yum to patch itself,
since opportunities to test this approach before putting it in motion will
be limited.
With regards to adding it to configure, we could certainly do that, and
it's probably a good idea. What do you propose configure doing? Here's my
tentative idea (assuming we don't use -noupdatecheck)
run amber_patch.yum --check-updates.
a) No additional updates: continue on your merry way
b) There ARE additional updates. Stop, say "there are updates. Do you wish
to download and apply them now?". If the user says "yes", run
`amber_patch.yum --update-amber`, then continue on our merry way (as long
as amber_patch.yum finished successfully).
If we want to avoid interactivity of the configure script, we just print
out a message saying "there are updates. Apply them using `amber_patch.yum
--update-amber` then re-run configure, or re-run configure with
-noupdatecheck" and quit.
c) What do we do for off-line users? Require the use of -noupdatecheck, or
just print a message saying we can't make the check and trudge on (knowing
that message won't be read ;)
--
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 Sat Nov 05 2011 - 00:00:02 PDT
