Fink:Major New Feature Plans:Patchfile Checksums

Current implementation

Syntax

Automatic application via an implicit patch -p1 < %a/foo.patch

Patch: foo.patch

and/or usage in explicit scripts:

PatchScript: sed 'some script' < %a/foo.patch | patch -p1

Problems

• No detection of corrupted patchfile.
• No protection against CVS problems that cause a .info to use the wrong revision of a .patch.
• If multiple .info use a common .patch, all maintainers of the .info have to coordinate their updates.
• In the PatchScript/sed usage, package building does not abort if the patchfile is missing or not readable(!).
• Feature-requests tracker #979713.
• Bugs tracker #1204001
• Fink-devel discussion.
• Fink-devel discussion a long time ago

Solution in CVS HEAD

Goals

• Old fink will fail hard if it attempts to use an .info file with the new syntax if that would succeed but give an incorrect build) if a BuildDepends:fink for the relevant fink version is accidentally omitted. Rather not resort to bumping to a new InfoN level.
• Explicitly state the patchfile filename so that fink can check that it exists, is readable, and is the maintainer-expected contents.
• Don't need strong checksumming (patchfile is stored on same server as infofile that lists the checksum).
• Quicker implementation and easier adoption than XMLish Source and Patch.

Syntax

Patchfile: foo.patch
PatchFile-MD5: hash-string

• A new %{PatchFile} would expand to the full path to the patchfile (%a/foo.patch in the old syntax).
• The %{default_script} for PatchScript contains the patch command to apply it. The only change in fink behavior vs old fields is that if there was Patch and an explicit PatchScript, will have to modify PatchScript to apply the patch instead of simply converting the Patch field to PatchFile.
• Could expand to PatchFileN and PatchFileN-MD5 if we want to continue to support multiple patchfiles.

Implementation

• At the beginning of PatchScript, fink checksums the file on disk, and abort immediately if it does not match. By always routing through the new percent-expansion token, we force this step to occur.
  • Using %a, .info could access a file that has not been checked.
  • Still allow %a for now so that .info would still work on older fink versions, but eventually abolish it at the same time the Patch field is abolished.
• Also check file readability as the user who will run the PatchScript.
• Fink always aborts when it encounters an unknown percent-expansion token, so we're protected against an old version of fink that silently mis-using a .info file with %{PatchFile}.
• Validator enforces a BuildDepends:fink that is versioned to require a fink that supports this new field. Not ideal, but if you're building a package whose .info doesn't validate, never any guarantees it'll work anyway.

"But Dan, Why Not...?"

• Can't do implicit application of the patch because that doesn't protect against mis-use by old-fink. The explicit use is easy and many packages already use explicit patch in PatchScript so there isn't a big learning curve here.
  • drm and akh feel that having validator check for BDep on a version of fink that supports this new feature is enough, so we will have implicit patching available.
• Can't just add PatchFile-MD5 for use vs the existing Patch because that allows leakage via %a and doesn't protect against missing patchfile when used by sed/patch. Also Patch can have more than one filename listed.
• Can't also have PatchFile-MD5 be used for patchfiles implemented by existing PatchScript because there's no foolproof way to get the filename out of that field. Also, there could be more than one filename used by the Patch and PatchScript fields.