[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-patch] Time for a new release?
From: |
Jean Delvare |
Subject: |
Re: [bug-patch] Time for a new release? |
Date: |
Mon, 16 Apr 2012 15:35:29 +0200 |
User-agent: |
KMail/1.12.4 (Linux/2.6.32.54-0.3-pae; KDE/4.3.5; i686; ; ) |
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
- [bug-patch] Time for a new release?, Jean Delvare, 2012/04/05
- Re: [bug-patch] Time for a new release?, Andreas Grünbacher, 2012/04/06
- Re: [bug-patch] Time for a new release?, Jean Delvare, 2012/04/10
- Re: [bug-patch] Time for a new release?, Andreas Grünbacher, 2012/04/12
- Re: [bug-patch] Time for a new release?, Mike Frysinger, 2012/04/12
- Re: [bug-patch] Time for a new release?, Andreas Grünbacher, 2012/04/12
- Re: [bug-patch] Time for a new release?, Andreas Grünbacher, 2012/04/13
- Re: [bug-patch] Time for a new release?, Mike Frysinger, 2012/04/13
- Re: [bug-patch] Time for a new release?, Andreas Grünbacher, 2012/04/14
- Re: [bug-patch] Time for a new release?,
Jean Delvare <=
- Re: [bug-patch] Time for a new release?, Andreas Grünbacher, 2012/04/16
- Re: [bug-patch] Time for a new release?, Jean Delvare, 2012/04/16
- Re: [bug-patch] Time for a new release?, Andreas Gruenbacher, 2012/04/17
- Re: [bug-patch] Time for a new release?, Jean Delvare, 2012/04/13