dependencies need to allow inclusion of variant

[jpm@…]

some ports will never be installed directly but rather as dependencies from other. it would be nice to allow the top level port to define a specific variant in its dependency rather than always dealing with the lowest common denominator...

[kevin@…]

* Bug 127 has been marked as a duplicate of this bug. *

[kevin@…]

Yes, this should be part of a larger goal to specify arbitrary options in a dependency. My current thinking is something along the lines of the following:

{bin:nethack:nethack +x11 option=value}

[kevin@…]

Reassigning bugs in my queue to where they belong.

[toby@…]

* Bug 3091 has been marked as a duplicate of this bug. *

[clubjuggler@…]

Cc Me!

[mf2k (Frank Schima)]

Cc Me!

[illogical1@…]

Cc Me!

[myschizobuddy@…]

Cc Me!

[myschizobuddy@…]

Now that a new PortMgr team is announced. would we see this in Macports soon?

[ryandesign (Ryan Carsten Schmidt)]

I think this bug was probably filed before any of the new PortMgr team ever heard of MacPorts. :) As least, it predates my involvement in the project, so it is nowhere on my list of things to do yet. I see Paul has been doing some work that may relate to this ticket (see r41526) but if you would like to discuss why this should be implemented and how it could be done, by all means bring it up on macports-dev. When a consensus is reached, more code can be written.

[bryan@…]

Cc Me!

[vinc17@…]

Cc Me!

[kngspook@…]

Cc Me!

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

This enhancement is required for a proper fix of #17452.

[ryandesign (Ryan Carsten Schmidt)]

As I wrote above two months ago, there hasn't yet been any decision on how or even whether this should be done. There certainly exist reasons why we would not want to implement this. By all means bring it up on macports-dev so it can be discussed.

[ocroquette (Olivier Croquette)]

Cc Me!

[ocroquette (Olivier Croquette)]

Are there any ways to at least warn the user if his current variant of the dependency doesn't fit ?

[ryandesign (Ryan Carsten Schmidt)]

The simplest would be to check whether a file you need is present or not. For example, if you need that port foo is installed with variant +bar, and variant +bar causes port foo to install the file ${prefix}/lib/libfoobar.dylib, then declare a dependency on port:foo and in the pre-fetch phase check if the file ${prefix}/lib/libfoobar.dylib exists, and if not, use return -code error to inform the user and exit.

[ocroquette (Olivier Croquette)]

OK, I will try that, thanks.

[jm@…]

A good example are the kdenlive + MLT + FFmpeg ports (some yet not committed to SVN). FFmpeg provides that codecs. MLT is the rendering and video engine. Kdenlive is only a GUI.

To work correctly, you need to install MLT with all FFMPEG variants. But what you consider a variant is not a variant but a real need in FFmpeg case.

So I expect most users to run "port install kdenlive". And this will install MLT with FFmpeg-devel. But with most codecs missings!

[ryandesign (Ryan Carsten Schmidt)]

Replying to jm@…:

But what you consider a variant is not a variant but a real need in FFmpeg case.

Then perhaps the ffmpeg port should be changed to have some of its variants removed and incorporated by default instead; you could file a separate ticket for that or discuss it with ffmpeg's maintainer.

[dbevans (David B. Evans)]

Personally, I favor including all of these variants as the default for ffmpeg as the utility of the library and app is the broad coverage that is provided. However, the opposing point of view is that the current port is just following the distribution's own distinctions at configure time as to what is default (ffmpeg's builit in codecs) and what is optional (codecs based on external libraries like libx264). So what is MacPorts policy on this. Is it permissible to make everthing the default? Or should we follow the developers lead? If the latter how about making a separate port (ffmpeg-full for example) that includes everything that can be depended upon by ports that need it.

[ryandesign (Ryan Carsten Schmidt)]

Discussion about changing the ffmpeg port should occur in a new ticket about ffmpeg, or on a MacPorts mailing list, not in this ticket.

[dbevans (David B. Evans)]

Replying to ryandesign@…:

Discussion about changing the ffmpeg port should occur in a new ticket about ffmpeg, or on a MacPorts mailing list, not in this ticket.

Sorry just responding to your lead.

[febeling@…]

Cc Me!

[anddam (Andrea D'Amore)]

Cc Me!

[pgnet.dev+macports@…]

Cc Me!

[jim@…]

Cc Me!

[jim@…]

Replying to ryandesign@…:

The simplest would be to check whether a file you need is present or not. For example, if you need that port foo is installed with variant +bar, and variant +bar causes port foo to install the file ${prefix}/lib/libfoobar.dylib, then declare a dependency on port:foo and in the pre-fetch phase check if the file ${prefix}/lib/libfoobar.dylib exists, and if not, use return -code error to inform the user and exit.

An example where this is tougher (and where almost none of the portfiles are committed yet):

I'm working to create a port for evolution-exchange@2.26.2, the Exchange connector for Evolution, the Gnome mail client. Ideally, a user who knows they want to plug Evolution into MS Exchange should be able to:

sudo port install evolution-exchange

... and everything else just fills in.

Here's the dependency chain:

• evolution-exchange@2.26.2 requires evolution@2.26.2+exchange
• evolution@2.26.2+exchange (which adds the config flag --with-exchange) requires evolution-data-server@2.26.2+exchange
• evolution-data-server@2.26.2+exchange (which adds the config flags --with-krb5 --with-openldap) requires openldap@2.3.35_2+evolution_ntlm
• openldap@2.3.35_2+evolution_ntlm ironically, applies an NTLM patch found in evolution-exchange-2.26.2/docs/openldap-ntlm.diff

The best part: evolution-data-server's ./configure looks to see that it can successfully link ldap_ntlm_bind and, if not, refuses to fail; instead, it just prints a warning (which is dutifully suppressed unless you run port -v ...) and continues without error, but without configuring NTLM on. But that's neither here nor there for this discussion.

I'm also aware that we can't do versioned dependencies. We'll ignore that for now, too.

In order to install Evolution fully ready to talk to Exchange, a user would have to type:

sudo port install openldap +evolution_ntlm
sudo port install evolution +exchange # this gets evolution-data-server too
sudo port install evolution-exchange

In the name of reducing user-facing complexity, I could:

• Name the openldap variant "exchange" which is consistent with the other ports, but less expressive of what the variant actually changes
• Add a dummy "exchange" variant to evolution-exchange

Then it would be:

sudo port install evolution-exchange +exchange

... which is a bit redundant, but survivable.

So I'm caught between a desire to package this accurately, which inflicts upon the user the need to understand all the moving parts in their many particulars, or the desire to help the user be successful, which makes the packaging kinda kludgy.

Sure would be nice to be able to specify

  depends_lib   port:evolution-data-server@${version}+exchange

... and have that resolve properly.

[vitaly@…]

Cc Me!

[stromnov (Andrey Stromnov)]

Cc Me!

[guillaume-jean@…]

Cc Me!

[staffan@…]

Cc Me!

[gustafn]

Cc Me!

[tehfink]

Cc Me!

[bernard@…]

Cc Me!

[cooljeanius (Eric Gallager)]

Cc Me!

[cooljeanius (Eric Gallager)]

So yesterday was the 10-year anniversary of this issue being opened on this issue tracker... I figured that would make this a good opportunity to ask for a status update as to whether any sort of progress has been made on this issue lately.

[ryandesign (Ryan Carsten Schmidt)]

The progress that has been made is that MacPorts now supports subports, which make it easier for a single portfile to provide multiple separately-installable ports. Ports that provide optional functionality that other ports might need to depend on should break that optional functionality out into subports instead of using variants. We should not pursue the idea of allowing variants to be depended upon.

[ocroquette (Olivier Croquette)]

Good to know, thanks for the update ! Just FYI, it looks like the subport feature is not documented yet on https://www.macports.org/guide/

[larryv (Lawrence Velázquez)]

It’s been real, #126, but I think we’ve de facto decided that subports are our solution to this issue. In any case, it sure doesn’t seem like anyone is ever going to work on it.

[cooljeanius (Eric Gallager)]

What about the active_variants portgroup​? Also, if subports are the solution, there's still the issue of documenting the feature, as seen in #36957

[neverpanic (Clemens Lang)]

I haven't given up on this, and I'm also going to propose fixing this in this year's GSoC.

[cooljeanius (Eric Gallager)]

Replying to cal@…:

I haven't given up on this, and I'm also going to propose fixing this in this year's GSoC.

So can this be re-opened then?

[macports@…]

cal: looking forward to it! I just stumbled upon this again with subsurface (which requires +quartz on a couple of dependencies).

[dliessi (Davide Liessi)]

Cc Me!

[larryv (Lawrence Velázquez)]

Has duplicate #41131.

[Polyergic (Shad Sterling)]

Cc Me!

[robertoschwald (Robert Oschwald)]

Cc Me!

[ra1nb0w]

CC Me!