Adam Conrad wrote on 09/11/2005 15:28: > Sven Mueller wrote: > >>I have been trying to backport your php5 package to sarge... > > To the best of my knowlege, it should "backport" with nothing more than > a recompile. It certainly has for me in the past. If that's not the > case for you, I'd like to hear about it.
I had trouble with one patch among all of your patches to not apply cleanly, causing the source tree to be in a state not recoverable automatically. Remember that policy mandates that even after an aborted build, "debian/rules clean" should put the source tree into a state suitable for "debian/rules binary" to succeed with funtionally equivalent result as if run on a freshly extracted source. Your patch system prevents that. >>Then replace your previous patch handling (patch, patch-stamp and >>unpatch targets) by including the dpatch makefile snippet... > > > I have no intention to switch to dpatch, as I much prefer the simple > patch system we're using right now. Give that its biggest problem > (patching configure.in and running autoconf) means that the clean target > doesn't always work right anyway, dpatch won't really fix anything for > us, and adds complexity. A tarball-in-tarball scheme would fix it, but > is far too much hassle, so I have no real motivation to change the > status quo. Though dpatch certainly isn't perfect (though I don't understand your remark about patching configure.in/running autoconf), it has one big advantage over your current system: It keeps track about which patches were applied, allowing an automated rollback of those patches. The second advantage might not be of that much interest to you, but dpatch-edit-patch really is a convenient way to edit the patches if needed. Also, in my opinion, dpatch would remove complexity from your debian/rules and not add complexity. regards, Sven
signature.asc
Description: OpenPGP digital signature
