Conflicting binary in dependency

[Aaron Madlon-Kay]

Thanks for the feedback, Ryan.

> 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?

That's the most convenient solution to be sure. I wasn't sure if, perhaps,
sqlite3 is such a prolifically depended-upon port that to keep things
lightweight it was using the amalgamation distro (building the tools
requires building from the full distro, and brings in the tcl dependency).

If there's no reason not to build the tools by default then I will do that.

Thanks,
Aaron

On Fri, Jan 13, 2017 at 8:52 AM Ryan Schmidt <ryandesign at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20170113/693c509f/attachment.html>