Date: Sun, 22 Nov 2015 08:27:36 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 204725] Mk/bsd.port.mk: makepatch inserts context junk after r401709 Message-ID: <bug-204725-13-UyJgSH9f2V@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-204725-13@https.bugs.freebsd.org/bugzilla/> References: <bug-204725-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204725 --- Comment #7 from John Marino <marino@FreeBSD.org> --- (In reply to Jan Beich from comment #6) I don't understand most of your response. The "local: 2: bad variable name" was the primary problem. It basically aborted the operation. However, I'm still on FreeBSD 9.2 on this test machine. "If makepatch cannot avoid screwing up multi-file patches ..." It clearly states both in the header and the commit message that if file X is modified by patch file A, B, and C, that it will combine all the changes and which patch it is appled to will vary. This is not "a screwup". If anything, the port maintainer could be blamed for allowing the situation, but sometimes it can't be helped if applying external patches. In such a case, a single patch may be temporarily moved before running "make makepatch" so the multipatch is generated the same way, and the single patch generated by hand. The assumption is the patches being regenerated do not apply without fuzz. ".. and any hunks applied before are *lost* because .orig file(s) now points to a patched version(s)" I'm not sure what you are talking about here. There are two ways to use makepatch. 1) regenerate (clean/extract/do-patch/makepatch) 2) update patches (clean/extract/do-patch/ <edit manually/new .orig>/makepatch There are no lost hunks. Unless you're still talking about a file that is patched multiple times (which again, should be avoided) "One way to fix this issue is to employ a VCS to record changes then export them back." I'm not interested in introducing a VCS requirement, nor do I see how that would even help. The "it can't restore multiple partial changes" issue is a rare use case that has a limited workaround and it's a publicized limitation. To tell somebody not to use a tool for a limitation that occurs around %0.1 of the ports ... how does that help anybody? However, I can't tell from your response. Does the attached patch cause "makepatch" to work as designed? -- You are receiving this mail because: You are on the CC list for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-204725-13-UyJgSH9f2V>