cygport no longer archives ${NAME}-${VERSION}-${RELEASE}.cygwin.patch into source package automatically

[Jon Turney]

On 27/11/2025 16:41, Corinna Vinschen via Cygwin wrote:
> On Nov 27 23:59, Takashi Yano via Cygwin wrote:
>> On Thu, 27 Nov 2025 14:20:31 +0000
>> Jon Turney wrote:
>>> On 27/11/2025 13:46, Takashi Yano via Cygwin wrote:
>>>> On Thu, 27 Nov 2025 16:57:37 +0900
>>>> Takashi Yano wrote:
>>>>> One year ago, cygport archives ${NAME}-${VERSION}-${RELEASE}.cygwin.patch
>>>>> into source package automatically. However, it does not seem to archive now.
>>>>>
>>>>> Is this intentional behaviour?
>>>
>>> Yes.
>>>
>>> I did some work a while ago to simplify the functionality this ancient
>>> and confusing mechanism provided.
>>>
>>> Briefly, the .cygwin.patch file is applied to an empty ${C} directory to
>>> create a set of files. Cygwin READMEs, custom post-install/pre-remove
>>> scripts and shell profile scripts found in ${C} are then automatically
>>> installed (as per the "Postinstall" chapter in the cygport reference
>>> manual).
>>>
>>> This is just strange, and kind of awkward to work with when building
>>> from a packaging repo, as you can't work directly with these files, only
>>> a patch which makes them.
>>>
>>> So I added a new mechanism where these files can be named in CYGWN_FILES
>>> and are directly included in the source archive, instead.
>>>
>>> [1]
>>> https://cygwin.com/cgit/cygwin-apps/cygport/commit/?id=0b0066f3e778f760ca36a4454fe52eb603f9cf9d
>>>
>>>> Downgrading diffutils to 3.10-1 solve the issue.
>>>
>>> I though this was a different change where there's a new (benign)
>>> warning in diff (about diff-ing against an empty or non-existent
>>> directory?) which leaks out through cygport (that I maybe need to work
>>> out how to squelch or avoid).
>>>
>>> But now you have me thinking that it's more serious than that?
>>
>> Yes. For example, currently, the source package of bvi includes
>> bvi-1.4.2-1.cygwin.patch, however, it will be lost if the source
>> package is rebuild in current environment.
> 
> Wouldn't it be better to drop .cygwin.patch entirely and create
> explicit patch files applied via PATCH_URI?

Imho, these things don't belong in patches at all, since they are just 
plain files.

Since the .cygwin.patch file in the bvi package only creates a README 
file (to be installed in usr/share/doc/Cygwin), the 'modern' solution is 
place it next to the cygport. (You don't even need to write 
CYGWIN_FILES="README", since that's the default if a file with that name 
exists).

(Of course, if you have other files (not the aforementioned README, 
post-install/pre-remove and shell profile scripts) that you want to add 
to the source package, you can (as always) just add them to SRC_URI, and 
then write instructions in your cygport to install them from $S as needed.


However, Takashi-san has identified a bug here:

cygport uses 'diff || true' to generate the patch (to avoid seeing the 
exit status of 1 that diff generates if there are differences), so 
cygport is swallowing any error reported by diff (exit status 2).

But it seems that diff 3.11 or 3.12 now considers it an error to diff 
against a non-existent directory (which is what cygport has been diffing 
  ${C} against to generate the .cygwin.patch file, since forever).

This is the cause of the 'diff: <blah> Is a directory' message seen 
while building a package - I'd thought this was just a warning, not 
realizing that it's an error but being ignored, and obviously prevents 
the .cygwin.patch file from being generated.

Anyhow, the fix seems relatively simple (to diff against an empty but 
existing directory instead), so I'll release a fixed version of cygport 
as soon as I'm able to...

(probably need to cook up some regression test to check that these 
.cygwin.patch files are generated, since I'd completely failed to notice 
that! Thanks very much to Takashi for pointing that out!)