Conflicting binary in dependency

[Aaron Madlon-Kay]

> 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 <jmr at 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