> Is "sqlite3 CLI shell" the 'sqlite3' binary that is already installed by the > sqlite3 port?
Yes. So as a separate port I would skip that binary and provide only sqldiff and sqlite3_analyzer. > I would think a separate port (or subport) would be better. A non-default > variant would not be available as an archive, and I don't like the idea of > adding a Tcl dependency to sqlite3 by default. Fair enough. I’ve got this working as a subport now. It seems my comments about the deactivate hack were only valid for the case of upgrading; when installing as a new port the dependencies are not upgraded, so the hack is required. Thanks, Aaron > On Jan 13, 2017, at 22:46, Joshua Root <j...@macports.org> wrote: > > On 2017-1-12 18:58 , Aaron Madlon-Kay wrote: >> Hi all. I was hoping to get some advice: >> >> I want to make the sqlite3-tools package available via MacPorts >> (binaries available at https://sqlite.org/download.html); this package >> contains three binaries: sqlite3 CLI shell, sqldiff, and sqlite3_analyzer. > > Is "sqlite3 CLI shell" the 'sqlite3' binary that is already installed by the > sqlite3 port? > >> Problem: >> >> 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. >> >> Questions: >> >> - 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? > > It's well known that Tcl 8.6 bundles all of sqlite3. Probably fine to remove > or rename this script though. > >> - 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? > > There's no standard scheme. The usual approach is to append the name of the > port to one of the files. > >> - 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) > > You think right. :) > >> Aside: >> >> 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. > > I would think a separate port (or subport) would be better. A non-default > variant would not be available as an archive, and I don't like the idea of > adding a Tcl dependency to sqlite3 by default. > > - Josh