Bug 247989

Summary: www/gitea: Allow changing the GITEA_CUSTOM path via rc.conf knob
Product: Ports & Packages Reporter: mikeg
Component: Individual Port(s)Assignee: Adam Weinberger <adamw>
Status: Closed FIXED    
Severity: Affects Some People CC: adamw, koobs, stb
Priority: --- Keywords: easy, feature
Version: LatestFlags: koobs: maintainer-feedback+
Hardware: Any   
OS: Any   
Bug Depends on: 247613    
Bug Blocks:    
Attachments:
Description Flags
Patch against SVN head none

Description mikeg 2020-07-15 07:49:12 UTC
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
Comment 1 Stefan Bethke 2020-07-18 10:15:41 UTC
Should get committed as part of 247613.
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2020-07-18 11:41:02 UTC
(In reply to mikeg from comment #0)

Is there a specific reason it's required to go in the same commit as bug 247613 ?
Comment 3 commit-hook freebsd_committer freebsd_triage 2020-07-18 12:35:43 UTC
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
Comment 4 Adam Weinberger freebsd_committer freebsd_triage 2020-07-18 12:38:18 UTC
Committed, thanks!
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2020-07-19 03:17:47 UTC
^Triage: Closed by bug 247613, leave depends on intact
Comment 6 Adam Weinberger freebsd_committer freebsd_triage 2020-07-19 03:45:23 UTC
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?
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2020-07-19 04:17:43 UTC
(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.