Dmacks: Reverted edit of YfyEbr, changed back to last version by Dmacks

2007-06-11T18:45:02Z

Reverted edit of YfyEbr, changed back to last version by Dmacks

New page

{{Fink_Header}}

==Current implementation==
===Syntax===
Automatic application via an implicit <code>patch -p1 < %a/foo.patch</code>
<pre>Patch: foo.patch</pre>
and/or usage in explicit scripts:
<pre>PatchScript: sed 'some script' < %a/foo.patch | patch -p1</pre>
===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(!).
* [http://sourceforge.net/tracker/?group_id=17203&atid=367203&func=detail&aid=979713 Feature-requests tracker #979713].
* [http://sourceforge.net/tracker/?group_id=17203&atid=117203&func=detail&aid=1204001 Bugs tracker #1204001]
* [http://thread.gmane.org/gmane.os.macosx.fink.devel/11916 Fink-devel discussion].
* [http://article.gmane.org/gmane.os.apple.fink.devel/9810 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 <code>BuildDepends:fink</code> for the relevant fink version is accidentally omitted. Rather not resort to bumping to a new <code>InfoN</code> 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 [[Fink:Major New Feature Plans:XMLish Source and Patch|XMLish Source and Patch]].

===Syntax===
<pre>Patchfile: foo.patch
PatchFile-MD5: hash-string</pre>
* A new <code>%{PatchFile}</code> would expand to the full path to the patchfile (<code>%a/foo.patch</code> in the old syntax).
* The <code>%{default_script}</code> for <code>PatchScript</code> contains the <code>patch</code> command to apply it. The only change in fink behavior vs old fields is that if there was <code>Patch</code> and an explicit <code>PatchScript</code>, will have to modify <code>PatchScript</code> to apply the patch instead of simply converting the <code>Patch</code> field to <code>PatchFile</code>.
* Could expand to <code>PatchFileN</code> and <code>PatchFileN-MD5</code> if we want to continue to support multiple patchfiles.
===Implementation===
* At the beginning of <code>PatchScript</code>, 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 <code>Patch</code> 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 <code>%{PatchFile}</code>.
* 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 <code>PatchScript</code> 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 <code>PatchFile-MD5</code> for use vs the existing <code>Patch</code> because that allows leakage via %a and doesn't protect against missing patchfile when used by sed/patch. Also <code>Patch</code> can have more than one filename listed.
* Can't also have <code>PatchFile-MD5</code> be used for patchfiles implemented by existing <code>PatchScript</code> 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 <code>Patch</code> and <code>PatchScript</code> fields.

{{Fink_Header}}

[[Category: Fink|New Feature Plans Patchfile Checksums]]
[[Category: Fink_Roadmap|New Feature Plans Patchfile Checksums]]
[[Category: Fink_Infofile_Syntax|New Feature Plans Patchfile Checksums]]

Fink:Major New Feature Plans:Patchfile Checksums - Revision history

Dmacks: Reverted edit of YfyEbr, changed back to last version by Dmacks