#24178 closed defect (fixed)
When patchfiles-delete deletes all patches in patchfiles, org.macports.patch crashes.
Reported by: | gellule.xg@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | MacPorts 1.9.0 |
Component: | base | Version: | 1.8.2 |
Keywords: | Cc: | ryandesign (Ryan Carsten Schmidt) | |
Port: |
Description
When patchfiles-delete is used on all the patch files listed in patchfiles, patchlist in portpatch.tcl becomes empty and errors with:
---> Applying patches to zlib Error: Target org.macports.patch returned: Patch files missing DEBUG: Backtrace: Patch files missing while executing "$procedure $targetname" Warning: the following items did not execute (for zlib): org.macports.activate org.macports.patch org.macports.configure org.macports.build org.macports.destroot org.macports.install Error: Status 1 encountered during processing. To report a bug, see <http://guide.macports.org/#project.tickets>
It seems like portpatch.tcl should be modified. Right after checking the non existence of patchfiles in portpatch::patch_main, the emptiness of patchfiles should be checked as well.
I'm attaching the portfile that caused the issue. It's a Portfile for zlib adding a nopatch variant that removes the only zlib patch from patchfiles.
Attachments (1)
Change History (4)
Changed 15 years ago by gellule.xg@…
comment:1 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign@… added |
---|
comment:2 follow-up: 3 Changed 15 years ago by raimue (Rainer Müller)
Milestone: | → MacPorts 1.9.0 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Fixed in r65243.
If we want to do that for all options we would either have to make no difference between unset and empty or add a new helper function checking both.
comment:3 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to raimue@…:
If we want to do that for all options we would either have to make no difference between unset and empty
Well, where do we differentiate between unset and empty, and why do we do so?
We had this issue in prior MacPorts versions with configure.args but we fixed it, but apparently only for that specific variable and not for all our list variables.