> Whatever you choose, anytime you move a file from being provided by one port > to being provided by another port, don't forget to use the deactivate hack in > the new port: > > https://trac.macports.org/wiki/PortfileRecipes#deactivatehack
Thanks for pointing this out. I added this, but I wonder if it’s necessary in this case: 1. I need to bump the revision of tcl to remove sqlite3_analyzer 2. At the same time, tcl becomes a dependency to the new revision of sqlite3 3. When upgrading sqlite3, because it is a dependency tcl appears to be upgraded first, resolving the conflict So it seems like the deactivate hack code will never be run. Thanks, Aaron > On Jan 13, 2017, at 8:52, Ryan Schmidt <ryandes...@macports.org> wrote: > > > On Jan 12, 2017, at 01: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. >> >> 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? >> > > I was not aware it was in the tcl port. Sounds like a good idea to remove it > from there. > >> - 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) >> >> 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. > > Is there a particular reason why it should be a variant, as opposed to just > always building and installing the tools in the sqlite3 port? > > Whatever you choose, anytime you move a file from being provided by one port > to being provided by another port, don't forget to use the deactivate hack in > the new port: > > https://trac.macports.org/wiki/PortfileRecipes#deactivatehack