Conflicting binary in dependency

Aaron Madlon-Kay aaron+macports at
Thu Jan 12 07:58:32 CET 2017

Hi all. I was hoping to get some advice:

I want to make the sqlite3-tools package available via MacPorts (binaries
available at; this package contains three
binaries: sqlite3 CLI shell, sqldiff, and sqlite3_analyzer.


sqlite3_analyzer requires TCL; it turns out the `tcl` port actually
includes sqlite3_analyzer built from its own bundled copy of sqlite3, but
it is an older version. This older version is installed to ${prefix}/bin,
so it conflicts with any newer version we might try to install.


- Is it common knowledge that sqlite3_analyzer is available as part of TCL?
Its inclusion there seems coincidental, perhaps just due to the fact that
it's implemented in TCL?
  - If no, can we remove it from the `tcl` port?

- If sqlite3_analyzer can't be removed from the `tcl` port, should the
newer binary have a different name or be put in a different path? Is there
a standard scheme for disambiguation like this?

- If no to all above, sqlite3_analyzer can be built against the
system-provided TCL framework, and the port can be marked as incompatible
with the `tcl` port. Is that acceptable? (I would think not)


I've got this working in two forms: a +tools variant on the `sqlite3` port,
and a new port called `sqlite3-tools`; I'm feeling like a the +tools
variant might be the better way to go, but feedback on this would be
appreciated as well.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the macports-dev mailing list