Opened 15 years ago

Closed 5 years ago

Last modified 5 weeks ago

#126 closed enhancement (wontfix)

dependencies need to allow inclusion of variant

Reported by: jpm@… Owned by: macports-tickets@…
Priority: Normal Milestone: MacPorts Future
Component: base Version:
Keywords: Cc: narf_tm@…, nox@…, clubjuggler@…, mf2k (Frank Schima), illogical1@…, ryandesign (Ryan Schmidt), bryan@…, vinc17@…, kngspook@…, MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), ocroquette (Olivier Croquette), dbevans (David B. Evans), febeling@…, anddam (Andrea D'Amore), jim@…, vitaly@…, stromnov (Andrew Stromnov), guillaume-jean@…, staffan@…, gustafn, djsnickles@…, bernard@…, cooljeanius (Eric Gallager), dliessi (Davide Liessi), Polyergic (Shad Sterling), robertoschwald@…, grimreaper (Eitan Adler)
Port:

Description (last modified by ryandesign (Ryan Schmidt))

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

Change History (58)

comment:1 Changed 15 years ago by kevin@…

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

comment:2 Changed 15 years ago by kevin@…

  • Status changed from new to assigned

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}

comment:3 Changed 13 years ago by kevin@…

  • Owner changed from kevin@… to darwinports-bugs@…
  • Status changed from assigned to new

Reassigning bugs in my queue to where they belong.

comment:4 Changed 12 years ago by toby@…

  • Cc narf_tm@… added

comment:5 Changed 12 years ago by toby@…

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

comment:6 Changed 11 years ago by pipping@…

  • Milestone set to MacPorts 1.5

comment:7 Changed 10 years ago by nox@…

  • Cc narf_tm@… nox@… added; narf_tm@… removed

comment:8 Changed 10 years ago by nox@…

  • Version 1.0 deleted

comment:9 Changed 10 years ago by nox@…

  • Priority changed from Expected to Normal

comment:10 Changed 10 years ago by jmpp@…

  • Milestone changed from MacPorts 1.5 to MacPorts base enhancements

comment:11 Changed 9 years ago by clubjuggler@…

  • Cc clubjuggler@… added

Cc Me!

comment:12 Changed 9 years ago by mf2k (Frank Schima)

  • Cc macsforever2000@… added

Cc Me!

comment:13 Changed 9 years ago by illogical1@…

  • Cc illogical1@… added

Cc Me!

comment:14 Changed 9 years ago by myschizobuddy@…

  • Cc myschizobuddy@… added

Cc Me!

comment:15 Changed 9 years ago by myschizobuddy@…

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

comment:16 Changed 9 years ago by ryandesign (Ryan Schmidt)

  • Cc ryandesign@… added
  • Description modified (diff)

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.

comment:17 Changed 9 years ago by bryan@…

  • Cc bryan@… added

Cc Me!

comment:18 Changed 9 years ago by vinc17@…

  • Cc vinc17@… added

Cc Me!

comment:19 Changed 9 years ago by kngspook@…

  • Cc kngspook@… added

Cc Me!

comment:20 Changed 9 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

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

comment:21 Changed 9 years ago by ryandesign (Ryan Schmidt)

  • Cc mcalhoun@… added

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.

comment:22 Changed 9 years ago by ocroquette (Olivier Croquette)

  • Cc ocroquette@… added

Cc Me!

comment:23 Changed 9 years ago by ocroquette (Olivier Croquette)

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

comment:24 follow-up: Changed 9 years ago by ryandesign (Ryan 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.

comment:25 Changed 9 years ago by ocroquette (Olivier Croquette)

OK, I will try that, thanks.

comment:26 follow-up: Changed 9 years ago by 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!

comment:27 in reply to: ↑ 26 Changed 9 years ago by ryandesign (Ryan 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.

comment:28 Changed 9 years ago by dbevans (David B. Evans)

  • Cc devans@… added

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.

comment:29 follow-up: Changed 9 years ago by ryandesign (Ryan 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.

comment:30 in reply to: ↑ 29 Changed 9 years ago by 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.

comment:31 Changed 9 years ago by febeling@…

  • Cc febeling@… added

Cc Me!

comment:32 Changed 8 years ago by anddam (Andrea D'Amore)

  • Cc and.damore@… added

Cc Me!

comment:33 Changed 8 years ago by pgnet.dev+macports@…

  • Cc pgnet.dev+macports@… added

Cc Me!

comment:34 Changed 8 years ago by jim@…

  • Cc jim@… added

Cc Me!

comment:35 in reply to: ↑ 24 Changed 8 years ago by 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.

comment:36 Changed 8 years ago by jmroot (Joshua Root)

  • Reporter changed from jpm@… to jpm@…

comment:37 Changed 8 years ago by vitaly@…

  • Cc vitaly@… added

Cc Me!

comment:38 Changed 8 years ago by stromnov (Andrew Stromnov)

  • Cc stromnov@… added

Cc Me!

comment:39 Changed 8 years ago by guillaume-jean@…

  • Cc guillaume-jean@… added

Cc Me!

comment:40 Changed 7 years ago by staffan@…

  • Cc staffan@… added

Cc Me!

comment:41 Changed 7 years ago by gustafn

  • Cc neumann@… added

Cc Me!

comment:42 Changed 7 years ago by djsnickles@…

  • Cc djsnickles@… added

Cc Me!

comment:43 Changed 7 years ago by bernard@…

  • Cc bernard@… added

Cc Me!

comment:44 Changed 5 years ago by cooljeanius (Eric Gallager)

  • Cc egall@… added

Cc Me!

comment:46 Changed 5 years ago by 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.

comment:48 Changed 5 years ago by ryandesign (Ryan 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.

comment:49 Changed 5 years ago by 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/

comment:52 Changed 5 years ago by ryandesign (Ryan Schmidt)

  • Cc testing1@… added; myschizobuddy@… pgnet.dev+macports@… removed

comment:53 Changed 5 years ago by larryv (Lawrence Velázquez)

  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:54 Changed 5 years ago by 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

Last edited 5 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:55 follow-up: Changed 5 years ago by neverpanic (Clemens Lang)

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

comment:56 in reply to: ↑ 55 Changed 5 years ago by 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?

comment:57 Changed 4 years ago by macports@…

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

comment:58 Changed 4 years ago by dliessi (Davide Liessi)

  • Cc davide.liessi@… added

Cc Me!

comment:59 Changed 4 years ago by larryv (Lawrence Velázquez)

Has duplicate #41131.

comment:60 Changed 4 years ago by Polyergic (Shad Sterling)

  • Cc me@… added

Cc Me!

comment:61 Changed 3 years ago by robertoschwald@…

  • Cc robertoschwald@… added

Cc Me!

comment:62 Changed 5 weeks ago by grimreaper (Eitan Adler)

  • Cc grimreaper added
Note: See TracTickets for help on using tickets.