Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.
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
Reply to: