Opened 21 years ago

Closed 20 years ago

Last modified 19 years ago

#1200 closed defect (fixed)

Disable Panther's evil patch(1) heuristics

Reported by: fenner@… Owned by: landonf (Landon Fuller)
Priority: Normal Milestone:
Component: base Version: 1.0
Keywords: Cc:
Port:

Description

Panther's patch(1) refuses to patch a file that is owned by someone else and not writable by you (even if you're root), if you have any of P4PORT, P4USER, or P4CONFIG set in your environment. This heuristic seems to assume that every file in the universe is in perforce.

I explored several possible solutions:

  • Unset P4PORT, P4USER, P4CONFIG in the environment not good because there's no defined way to do this; default patch.env {"unset P4PORT P4USER P4CONFIG;"} works but that's more of an accident than anything.
  • Pass -g0 to patch. This is no good because -g is not portable.
  • Pass --no-same-owner to tar, so the files end up owned by root. This is no good because --no-same-owner is not portable.

The best solution I've come up with is to set POSIXLY_CORRECT in patch's environment, which is similar to -g0 except it's an environment variable that will be ignored by patch programs that don't support -g0. I don't know what other side effects POSIXLY_CORRECT might have; hopefully none are negative.

Attachments (1)

portpatch.tcl.diff (518 bytes) - added by fenner@… 21 years ago.
Patch for portpatch.tcl that sets POSIXLY_CORRECT in the defualt environment.

Download all attachments as: .zip

Change History (5)

Changed 21 years ago by fenner@…

Attachment: portpatch.tcl.diff added

Patch for portpatch.tcl that sets POSIXLY_CORRECT in the defualt environment.

comment:1 Changed 21 years ago by landonf@…

Status: newassigned

If you just default patch.env, it can be overwritten by a port that specifies patch.env.

I would append POSIXLY_CORRECT to patch.env later on, ie, right before calling 'command' for patch.

comment:2 Changed 21 years ago by landonf@…

Owner: changed from darwinports-bugs@… to landonf@…
Status: assignednew

comment:3 Changed 20 years ago by landonf@…

Resolution: fixed
Status: newclosed

I committed a patch to fix this. Thanks!

comment:4 Changed 19 years ago by jpm@…

i am still seeing this issue on TOT, is there something else that needs to be done?

jpm.lecheval ~/Desktop/ -=> port install privoxy ---> Fetching privoxy ---> Verifying checksum(s) for privoxy ---> Extracting privoxy ---> Applying patches to privoxy Error: Target com.apple.patch returned: shell command "cd "/Volumes/local/Users/jpm/sandbox/ darwinports/dports/www/privoxy/work/privoxy-3.0.3-stable" && patch -p0 < "/Volumes/local/Users/ jpm/sandbox/darwinports/dports/www/privoxy/files/patch-GNUmakefile.in"" returned error 2 Command output: patch: File GNUmakefile.in seems to be locked by somebody else under Perforce

Note: See TracTickets for help on using tickets.