retitle 485330 Allow context diff in debian/patches/ in 3.0 (quilt) format thanks
On Thu, 06 Aug 2009, Pierre Habouzit wrote: > That said, yes, using non-unified diff is as laughable as using RCS or > SCCS nowadays. Though I consider it a bug if dpkg refuses to apply a > patch that patch(1) (that it uses in the end) would apply fine. I shall > say that I absolutely don't get why there even is an "analyze()" routine > in Patch.pm, analyze() extracts information from the patch in order to: - create directories that do not exist yet (patch will not do that for you AFAIK or at least that's the assumption that the current codebase made, it might have changed since this part of the code has been written) - have a listing of all modified files in order to harmonize their timestamp afterwards (required to avoid unwanted rebuilding when patching auto-generated files and their source file) Extracting those information require to parse the patch files, so why not error out when the parser finds something not allowed? So while I have no opposition to allowing patches in context format (and not other non-contextual ones), the fix is most likely not the short one proposed by Charles. Instead the Dpkg::Source::Patch object should have full support of the context format at least in the analyze() part. > if you want that, let patch(1) do it using its --dry-run > mode. It'll report failed hunk and bad syntax the same way. You'll be surprised how much permissive patch actually is. IIRC missing context in unidiff is not always fatal for example (even when the numbers on the @@ lines stipulate that there should be more lines than what there is). Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
