[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 6 May 2011 20:06:35 -0500
From: "JimF" <jfoug@....net>
To: <john-users@...ts.openwall.com>
Subject: Re: Plumbing changes (was: Re: Following all the patch activity, not uploading to the wiki, which patches play well together, revising the wiki page to be better)
That sounds like a wonderful addition.
However, somewhere, there still will likely be a spot with major patch
clashes. load formats is one of them. Every new format has to be declared
at 'some' point. One possible work around here, would be special include
files or something where each developer got his own. Then if he only
changes that header, he would not impact anyone elses changes. Including a
source file is semi non-standard, but is one way to work around the multiple
patching collisions. Those changes (and the params 'version string'), seem
to be the place with the most collisions. We could get around the params.h
change, by simply having only ONE person that can change that one (solar),
and then if we need to, have multiple additional outputs again, in our own
private developer headers, which could be output on a version check page.
So then it would list 1.7.7 jumbo-1 and then list additional lines, for the
other patches installed. The jumbo would set each developers private
header version string to "", and then they can make changes as they see fit,
to their own string.
Just talking off the cuff here.
Jim.
----- Original Message -----
From: "magnum" <rawsmooth@...dband.net>
> Maybe I should also implement that "auto-generated format list" for
> options.c that I have been thinking about... this would mitigate a lot of
> patch collisions. Together with your changes, most new formats would only
> add one line in Makefile and two in john.c
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux -
Powered by OpenVZ