Re: [bug-patch] Time for a new release?

[Jean Delvare]

Hi Andreas,

On Saturday 14 April 2012 02:34:45 pm Andreas Grünbacher wrote:
> There was another bug in the previous snapshot. The following
>  snapshot should be close to ready now:
> 
>   ftp://alpha.gnu.org/gnu/patch/testing/patch-2.6.1.164-028f.tar.gz

I am testing this version of GNU patch in conjunction with quilt and I 
am facing a problem. Not a bug proper, but rather a problematic 
behavioral change.

Until now, patch would happily work on read-only files. Now it is no 
longer, it will detect read-only files and refuse to operate on them, or 
at least complain loudly for every read-only file, if forced.

It happens that operating on read-only file is something I often do (and 
every other kernel developer at Suse too.) We work on parallel (hard-
linked) kernel trees, and we keep these read-only to avoid accidentally 
corrupting another tree in the group. Files should never be made 
writable before they have been unlinked (typically by applying a patch 
or adding the file to an existing patch.)

So with the latest version of GNU patch, every "quilt push" results in a 
warning about read-only files. This is rather inconvenient and passing 
--quiet doesn't even make it go away. And "quilt push -f" fails. Bad.

I do agree that the previous behavior (silently operating on read-only 
files by default) was wrong, but I think the new behavior is wrong too. 
If I tell patch to operate on a read-only file with --backup option (as 
quilt does), it would seem that I know what I'm doing. So I think 
patching read-only files should be as silent and successful as it used 
to be as long as --backup option is used.

You may argue that quilt should make the files writable by itself before 
calling patch, however it can't be done easily for two reasons. First 
reason is that quilt relies on patch to get the list of files affected 
by a patch file. If we have to extract this list from the patch file 
ourselves, this will add a lot of non-trivial code, which may (and will) 
diverge from GNU patch [1]. Second reason is that we don't want to make 
files writable before they are unlinked from the reference tree, and we 
can't unlink before we backup the file, otherwise the link will be lost 
forever and not restored when we revert (quilt pop) the patch. Backup 
(and unlinking) is done by GNU patch currently [2].

[1] I presume this could be worked around by calling patch --dry-run 
first, but this has a performance cost, obviously, which I'd like to 
avoid.
[2] We could have quilt take care of the backup and unlinking, but again 
at a performance cost, as an extra file copy would be required.

So, can we please agree on making GNU patch operate successfully and 
silently on read-only files whenever --backup option is used?

Thanks,
-- 
Jean Delvare
Suse L3