Allow having both tcl & tk set as dependencies.

[mat]

Summary

This is so the dependency on tcl is not proxied through the one on tk.

[mat]

The way around this (that is, not fixing but hiding the bug) is to change Mk/Scripts/qa.sh around lines 540 so that it does not complain about tcl if tk is there.

[gahr]

What about using the approach in https://bugs.freebsd.org/211261 ?

[mat]

In D7138#151205, @gahr wrote:

What about using the approach in https://bugs.freebsd.org/211261 ?

Well, ports may use tk and not tcl.

[gahr]

In D7138#151216, @mat wrote:

In D7138#151205, @gahr wrote:

What about using the approach in https://bugs.freebsd.org/211261 ?

Well, ports may use tk and not tcl.

Isn't the whole point of this to register a dependency on Tcl when a port depends on Tk?

[mat]

In D7138#151217, @gahr wrote:

In D7138#151216, @mat wrote:

In D7138#151205, @gahr wrote:

What about using the approach in https://bugs.freebsd.org/211261 ?

Well, ports may use tk and not tcl.

Isn't the whole point of this to register a dependency on Tcl when a port depends on Tk?

No, the point is to be able to do USES=tcl, USES=tk, and USES=tcl tk, where all three do the thing it feels like they should be doing, add a dep on tcl, add a dep on tk, add a dep on both.

If a port only needs tk, it should not register a dependency on tcl. The same way that if a port depends on both tcl and tk, it should not rely on tk to bring in tcl.

It is the whole point of the proxydeps qa check, to make sure a port really list all the dependencies it needs and does not rely on its dependencies to bring whatever it really needs. Which this what this patch does, allow the porter to select tcl, tk, and both, not forcing tcl if only tk is needed.

[gahr]

In D7138#151241, @mat wrote:

In D7138#151217, @gahr wrote:

In D7138#151216, @mat wrote:

In D7138#151205, @gahr wrote:

What about using the approach in https://bugs.freebsd.org/211261 ?

Well, ports may use tk and not tcl.

Isn't the whole point of this to register a dependency on Tcl when a port depends on Tk?

No, the point is to be able to do USES=tcl, USES=tk, and USES=tcl tk, where all three do the thing it feels like they should be doing, add a dep on tcl, add a dep on tk, add a dep on both.

The second and the third are equivalent. Tk is a Tcl extension by all means. To depend on Tk implies to depend on Tcl.

If a port only needs tk, it should not register a dependency on tcl. The same way that if a port depends on both tcl and tk, it should not rely on tk to bring in tcl.

I think this is counter intuitive at best.

It is the whole point of the proxydeps qa check, to make sure a port really list all the dependencies it needs and does not rely on its dependencies to bring whatever it really needs. Which this what this patch does, allow the porter to select tcl, tk, and both, not forcing tcl if only tk is needed.

Why would this be a problem (to rely on its dependencies to bring whatever it really needs)?

[mat]

In D7138#151244, @gahr wrote:

In D7138#151241, @mat wrote:

In D7138#151217, @gahr wrote:

In D7138#151216, @mat wrote:

In D7138#151205, @gahr wrote:

What about using the approach in https://bugs.freebsd.org/211261 ?

Well, ports may use tk and not tcl.

Isn't the whole point of this to register a dependency on Tcl when a port depends on Tk?

No, the point is to be able to do USES=tcl, USES=tk, and USES=tcl tk, where all three do the thing it feels like they should be doing, add a dep on tcl, add a dep on tk, add a dep on both.

The second and the third are equivalent. Tk is a Tcl extension by all means. To depend on Tk implies to depend on Tcl.

I always stayed away from tcl, the only time I used it was because way back when, it was the only way to write IRC bots.

If a port only needs tk, it should not register a dependency on tcl. The same way that if a port depends on both tcl and tk, it should not rely on tk to bring in tcl.

I think this is counter intuitive at best.

If you can tell me that there is no possible scenario on earth where some port will need libtk.so and not libtcl.so, then the patch from the PR is good.

It is the whole point of the proxydeps qa check, to make sure a port really list all the dependencies it needs and does not rely on its dependencies to bring whatever it really needs. Which this what this patch does, allow the porter to select tcl, tk, and both, not forcing tcl if only tk is needed.

Why would this be a problem (to rely on its dependencies to bring whatever it really needs)?

Because it is our policy, a port depends on stuff, then it depends on it, it doesn't hope a dependency will bring what it needs.

[gahr]

In D7138#151355, @mat wrote:

In D7138#151244, @gahr wrote:

In D7138#151241, @mat wrote:

In D7138#151217, @gahr wrote:

In D7138#151216, @mat wrote:

In D7138#151205, @gahr wrote:

What about using the approach in https://bugs.freebsd.org/211261 ?

Well, ports may use tk and not tcl.

Isn't the whole point of this to register a dependency on Tcl when a port depends on Tk?

No, the point is to be able to do USES=tcl, USES=tk, and USES=tcl tk, where all three do the thing it feels like they should be doing, add a dep on tcl, add a dep on tk, add a dep on both.

The second and the third are equivalent. Tk is a Tcl extension by all means. To depend on Tk implies to depend on Tcl.

I always stayed away from tcl, the only time I used it was because way back when, it was the only way to write IRC bots.

If a port only needs tk, it should not register a dependency on tcl. The same way that if a port depends on both tcl and tk, it should not rely on tk to bring in tcl.

I think this is counter intuitive at best.

If you can tell me that there is no possible scenario on earth where some port will need libtk.so and not libtcl.so, then the patch from the PR is good.

That is exact. Think of Tk being qt5-gui and Tcl being qt5-core.

I will approve the PR. Can you please close this review?

Thanks!