Created attachment 216458 [details] Patch against SVN head Quick two-line change so the rc.d script allows GITEA_CUSTOM to be pointed somewhere other than the default. Preserves /usr/local/etc/gitea (%%PREFIX%%/etc/${name}) as the default. Mainly useful if you have a lot of "stuff" in your custom directory like we do and don't want it cluttering up /usr/local/etc
Should get committed as part of 247613.
(In reply to mikeg from comment #0) Is there a specific reason it's required to go in the same commit as bug 247613 ?
A commit references this bug: Author: adamw Date: Sat Jul 18 12:35:15 UTC 2020 New revision: 542495 URL: https://svnweb.freebsd.org/changeset/ports/542495 Log: gitea: Update to 1.12.2 This release fixes a large number of bugs and introduces many new features. Release notes: - https://blog.gitea.io/2020/06/gitea-1.12.0-and-1.12.1-are-released/ - https://blog.gitea.io/2020/07/gitea-1.12.2-is-released/ Additional changes to the port: - Use PORTDATA to avoid enumerating the extensive DATADIR - Add option to rc file for custom path [1] - Turn the BINDATA option on by default PR: 247613, 247989 [1] Submitted by: maintainer, mikeg bsd-box net [1] Approved by: maintainer [1] Changes: head/www/gitea/Makefile head/www/gitea/distinfo head/www/gitea/files/gitea.in head/www/gitea/files/patch-vendor_github.com_go-git_go-git_v5_storage_filesystem_dotgit_dotgit.go head/www/gitea/pkg-message head/www/gitea/pkg-plist
Committed, thanks!
^Triage: Closed by bug 247613, leave depends on intact
Thanks, Koobs. It wouldn't let me close it initially because 247613 was open. Is setting the depends-on to "in-progress" enough to close dependent bugs? Unless I'm mistaken, that's what you did here, is that correct?
(In reply to Adam Weinberger from comment #6) I anticipate that this is a Bugzilla issue, allowing a "Depends On" to be added to a still-open dependent bug *after* the dependent has been closed (but not before). Logically, it's not possible to 'resolve a bug' if it depends on unclosed issues. That there is a 'followup' after the initial commit on bug 247613 is why we're in ambiguous territory. 'After the fact', the usual approach to resolve this: - Treat the followup as a 'separate issue' - Leave the dependent open until the dependency is closed I'd do the latter, however the better approach would have been to commit this bug separately and before bug 247613, which was the basis for my question in comment 2 This would have decoupled (removed) the dependency, which appears to be spurious in that it doesn't 'actually' require this update to be in the same commit or post-commit after the version update. Additionally, this change could have been merged, whereas the version update (if its a feature release), couldn't have been.