Apache OpenOffice (AOO) Bugzilla – Issue 40246
please support more than one patchfile
Last modified: 2013-08-07 15:34:52 UTC
Hi, somethimes it is required to have more than one patchfiles to apply. For example when there is some patch you need in one case but not in another and you don't want to clobber the original patch. Example just happening in cws_srx645_mozooo. If you build with system freetype (or build moz outside the normal flow and you automatically use system freetype) you get a build failure with freetype 2.1.8. There's a patch to fix that; it would apply to both existing patches but I a) don't want to clobber them with that and b) don't duplicate them but just put it in one patch to be applied in certain conditions instead of appending it to each of them... Regards, Rene
*** Issue 40247 has been marked as a duplicate of this issue. ***
well, the reason in mozooo apparently does not exists anymore, but it would be good neverthless for ocassions in the future :-)
the main idea behind the current patch handling is to automate and standardize as well applying patches as creating patches as much as possible. at least automated patch creation would be close to impossible when supporting more than one patch file in this process. this in return tends to decrease the portability of patches. also the chance to get problems with reapplied patches would increase (though it'salready possible with one patch file created by hand ;-)) in some rare cases it might be neccessary to have more than one patch file as a temporary workaround at the cost of breakingpatch creation. but supporting unlimited numbers of patch files (ok, this was polemic ;-)) IMHO is a step backwards.
.
Created attachment 50181 [details] possible patch to implement this
Created attachment 50182 [details] purely for example purposes a demo in rhino
cmc->hjs/rene: How about this implementation to allow multiple patches, seems to work for me. I'd prefer multiple patches for the externals because we have no idea looking at our existing patches what the hell they're really for as we've bundled into a single patch the fixes for build problems, warning as errors and enhancements. It would be *way* more preferable to have them split up, at least new ones, into one per purpose. Ideally even with an upstream bugzilla id in the patch name where it was submitted back to those probjects for a warning fix or the enhancement added by OOo. For example the rhino patch is horrific. Part of it I've unpicked to figure out that it merely updates it to the next patch level or two of rhino, while the other part is the substantive customization for OOo while the next part is just to add a makefile.mk to build it with dmake and the final part is to add in those otherly-authored java files from the original Sun tutorial on extending rhino. As part of the solenv suggestion attached here is a gendiff.sh diff maker which follows the same pattern that we use in fedora to help the auto patch making process.
Much interested in this [mainly for ICU, of course]. The current patch handling makes it awfully awkward to upgrade an external library if there were patches applied already. Once patches are accumulated in the one big patch file there's no chance to identify whether single patches are still needed other than reading the entire patch file, heck you even have to know which files belong together if a patch touched more than one file, even more because when regenerating the patch file, file dates are updated on each iteration.
why is this assigned to me?
hmm, did I assign it to you ? cmc->hjs: What do you think of the second approach ala gendiff ? "automate and standardize applying patches as well as creating patches as much as possible." does sort of require a change of practice from the current mechanism in order to auto-generate patches, but supports multiple "per-feature" patchsets so build-fixes can be kept separate from adding-feature patches
beside that the patch is a bit stale meanwhile (ok, i didn't pay too much attention when it was new...), the applying part isn't the problem. what i don't like is the generation part that involves too much manual copying. why not diffing the the changed tree with a reference tree already containing all patches beside the current change? this difference would make up a new patch that's generated and just has to be added to the makefile, as in your approach. what i want to keep is the cycle of change, build that change and create a patch containing exactly that change. without introducing manual steps that give you a tree that builds fine but will give you an incomplete patch because you forgot to copy something to somewhere in advance. the only drawback i see in that scenario is that you'll only be able to create new patches. changing existing ones will be a hassle and probably end up in creating all existing patches from scratch if the overlap is too big. and yes, it will be slower than gendiff as you always compare the whole tree but i think it's worth it...
I like that idea :-)
Created attachment 58263 [details] something like this I guess
Created attachment 58264 [details] sample usage for e.g. rhino
this path still assumes that patches reside in the module root. see jfreereport for an example.
Created attachment 58290 [details] quite untested but survives jfreereport on linux
oh man, {$(PATCH_FILES)} expands to something useful. You do know you're probably the only person on the planet that knows dmake makefile.mk syntax :-)
Looks good now on CWS ause099. Verified.