There is a bug in the validator handling of PatchFile filenames with varianted percent-expansion:
Package: foo-py%type_pkg[python]
Type: python (2.7 3.10)
PatchFile: %n.patch
PatchFile-MD5: [the correct checksum]
This expands to a patchfile of, for the 3.10 variant, "foo-py310.patch". If the file is actually "foo-py.patch" (unvarianted) then validator does not complain but it fails at build-time:
Failed: Cannot read PatchFile "/sw/fink/dists/stable/main/finkinfo/text/foo-py310.patch"
And if the .patch is actually named "foo-py310.patch", then validator complains:
Error: can't read PatchFile. (foo-py.patch)
Failed: unable to read from foo-py.patch: No such file or directory
and all variants except 3.10 fail at build-time because they instead look for a varianted filename other than "310". If a .info wants to apply a patch only for certain variants, it still needs a constant filename, and it's up to PatchScript to figure out whether to apply it.
If the .info correctly has
then both validator and buildtime are happy. Validator must be discarding the variant token. Oops.
There is a bug in the validator handling of PatchFile filenames with varianted percent-expansion:
This expands to a patchfile of, for the 3.10 variant, "foo-py310.patch". If the file is actually "foo-py.patch" (unvarianted) then validator does not complain but it fails at build-time:
And if the .patch is actually named "foo-py310.patch", then validator complains:
and all variants except 3.10 fail at build-time because they instead look for a varianted filename other than "310". If a .info wants to apply a patch only for certain variants, it still needs a constant filename, and it's up to PatchScript to figure out whether to apply it.
If the .info correctly has
then both validator and buildtime are happy. Validator must be discarding the variant token. Oops.