[Bug 274848] textproc/py-CommonMark: rename bin/cmark to bin/cmark-py for conflict avoidance

From: <bugzilla-noreply_at_freebsd.org>
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.