[csw-maintainers] [csw-pkgsubmissions] patching made simpler?
Ben Walton
bwalton at opencsw.org
Thu Jan 6 02:30:24 CET 2011
Excerpts from rupert THURNER's message of Wed Jan 05 14:12:46 -0500 2011:
Hi Rupert,
I'm sorry this wasn't easier for you.
> * try to build, not all patches applied
> * throw away the old patches, check in
First, a recommendation: Never throw away patch/script/foo files from
an existing build until you've got a working replacement. I've kicked
myself a few times for doing this. :)
In a situation like this, I'd see if I could get the patches to apply
manually using patch or other methods.
> * "gmake extract" to get the source back
> * edit the files again like it should be
Although it may not complain, makepatch would prefer to be called
after `gmake patch` to ensure all existing patches are applied. I
forget whether I enforced this with a constraint or not...If not, I
don't recall a the reason why I didn't.
> * "gmake makepatch"
> * "gmake package", failed as there is a new file which would need
> patching as well.
> * "gmake clean", "gmake extract" again
> * edit the file
> * "gmake makepatch" again
Did you see your first patch applied in this process at all? If not,
you're working on a pre-patched set of files.
> then i forgot to delete a line in a file which is already patched, and
> i thought about repeating above procedure again:
> 1. gmake extract
> applied patch 001
> 2. gmake makepatch
> tried to apply patch 001 again
> which failed.
This is likely due to creating a patch against the unpatched tree
above. If so, I should look at making sure makepatch cannot run
unless the patch target has already been called. You could,
potentially still have problems though...
> then i gave up for the moment ... but this cannot be it, isn't it?
> should we switch to the whole source from subversion to git and it
> would be neater? then patches could be rebased instead of applied
> newly.
I wouldn't object[1], but others may disagree. It's also a huge
undertaking. I know that many others are also using git quite a bit
lately too.
The first major portion of this transition would require separating
GAR (the tool) from the build recipes. Git simply doesn't handle
(nicely) the idea of an external like subversion does. This would be
the final impetus to separate the two, most likely using Sebastian's
excellent mgar!
I know that Maciej has been having both success and frustration using
the git-svn bridge as of late...
Thanks
-Ben
[1] It would actually make my day!
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
More information about the maintainers
mailing list