Created attachment 171928 [details] patch Update includes few commits past 4.1.6 because two bugs had to be fixed in the release. Therefore the name is 4.1.6e.
- Why do you use unofficial version and GH_TAGNAME? There's official 4.1.6 and it's more recent than 25959f1. - Why do you move REINPLACE_CMD in do-install:?
> - Why do you use unofficial version and GH_TAGNAME? There's official 4.1.6 and it's more recent than 25959f1. The re-did the 4.1.6 release 5 hours ago. The original 4.1.6 release was done 3 days ago and had problems that I reported 2 days ago: https://github.com/Aries85/LightZone/issues/177 and https://github.com/Aries85/LightZone/issues/178 > - Why do you move REINPLACE_CMD in do-install:? This way it doesn't conflict with patch to the same file, and the patch can be regenarated with makepatch.
Created attachment 171962 [details] patch Update to the second revision of lightzone 4.1.6 release.
(In reply to yuri from comment #2) > This way it doesn't conflict with patch to the same file It doesn't confclict. post-patch is executed before patches are applied as the target name suggests > and the patch can be regenarated with makepatch. Threre are a lot of ways do this (make extract do-patch && make makepatch), and even if there were not, it's not a reson to move patching where it doen't belong. Please put in back to post-patch.
Created attachment 172116 [details] patch Actually the patch under files/ wasn't important any more, and I deleted it. However, in cases when the patch under files/ is really needed, and that same file is also patched with some variable like LOCALBASE, the FreeBSD ports framework has a problem that patches write over each other, and your solution of "make extract do-patch && make makepatch" also doesn't work because this isn't what people normally do, and later the maintainer will likely forget this, will get confused, and possibly damage the patch.
(In reply to yuri from comment #5) > Actually the patch under files/ wasn't important any more, and I deleted it. > > However, in cases when the patch under files/ is really needed, and that > same file is also patched with some variable like LOCALBASE, the FreeBSD > ports framework has a problem that patches write over each other, and your > solution of "make extract do-patch && make makepatch" also doesn't work > because this isn't what people normally do, and later the maintainer will > likely forget this, will get confused, and possibly damage the patch. We've been living with this for years and I haven't seen any problems ever. Maintainers and committers must check diffs before submitting/committing so such problems are easily revealed. But it's true that patching the same file twice should be avoided.
A commit references this bug: Author: amdmi3 Date: Tue Jul 5 19:34:01 UTC 2016 New revision: 418110 URL: https://svnweb.freebsd.org/changeset/ports/418110 Log: - Update to 4.1.6 - While here, add LICENSE_FILE PR: 210677 Submitted by: yuri@rawbw.com (maintainer) Changes: head/graphics/lightzone/Makefile head/graphics/lightzone/distinfo head/graphics/lightzone/files/
(In reply to Dmitry Marakasov from comment #6) > We've been living with this for years and I haven't seen any problems ever. Who are those people who you call "we"? I saw problems with this quite a few times. Yuri