[Bug 274848] textproc/py-CommonMark: rename bin/cmark to bin/cmark-py for conflict avoidance
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 01 Nov 2023 11:18:55 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274848 Bug ID: 274848 Summary: textproc/py-CommonMark: rename bin/cmark to bin/cmark-py for conflict avoidance Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: Individual Port(s) Assignee: romain@FreeBSD.org Reporter: jcfyecrayz@liamekaens.com Assignee: romain@FreeBSD.org Flags: maintainer-feedback?(romain@FreeBSD.org) Nothing in the ports tree that I found depend on bin/cmark from textproc/py-CommonMark. To avoid conflicts with textproc/cmark (and allow removal of secondary conflict marking like 'DOCS_CONFLICTS_BUILD=cmark' in devel/llvm*), renaming bin/cmark in textproc/py-CommonMark to bin/cmark-py seems like a reasonable option. There is a (slight?) POLA concern that existing downstream users will be affected by this change. Adjusting to the change by looking for cmark-py does not seem particularly onerous. Encouraging the upstream project to do so is perhaps even better. I will pursue that as well. On github, commonmark/cmark (for textproc/cmark) and readthedocs/commonmark.py (for textproc/py-CommonMark) both started in 2014 with commonmark/cmark barely "winning" by a month or so. There's no clear "prior art" winner based on that distinction. But I suspect most py-CommonMark users use it as a python module rather than the command line tool. In the ports tree py-recommonmark uses py-CommonMark and certainly uses it purely as a python module rather than invoking bin/cmark. -- You are receiving this mail because: You are the assignee for the bug.