Subject: problem when patch(1)ing files in target location
To: None <email@example.com>
From: Luke Mewburn <firstname.lastname@example.org>
Date: 06/19/2001 21:06:59
A problem I've noticed with various packages is that they use patch(1)
to apply fixes to the target files, which the package then expects
will create a .orig file. Most (all) packages in this situation
attempt to remove the .orig file, but some don't use rm -f so they'll
fail if the .orig file doesn't exist.
There is a problem here; patch(1) doesn't always create .orig files;
it may use other extensions. This is controlled by the following
options to patch:
-b suffix (also $SIMPLE_BACKUP_SUFFIX)
-V method (also $VERSION_CONTROL)
Thus, if you have $VERSION_CONTROL=t (which I do), patch will create
numbered backups instead of .orig files, and the packages that assume
that .orig files will be created, then you lose, and often it's only
when you delete the package and there's an unexpected foo.~1~ file lying
around (e.g, /usr/pkg/lib/netscape/navigator-4.75/bookmark.htm.~1~)
I propose that bsd.pkg.mk is modified so that patch(1) is invoked
-V simple -b .orig
to ensure that known behaviour occurs.
I leave it to the pkg people to actually implement this in The Correct
Way. I'm just highlighting a problem I experience fairly regularly.
Luke Mewburn <email@example.com> http://www.wasabisystems.com
Luke Mewburn <firstname.lastname@example.org> http://www.netbsd.org
Wasabi Systems - providing NetBSD sales, support and service.