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!)
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
