Allow multiple ports to satisfy a single dependency

[rhwood@…]

Currently there is no mechanism to specify that multiple ports may satisfy a single dependency requirement. It would be nice to be able to do so. I can think of two ways this can be done:

OR dependencies

Allow dependencies to be specified in the following fashion:
port:able|baker|charlie
where the pipe is used to separate one or more ports that may satisfy a single dependency. The first port would be used if none of the ports are installed. There should be no limit to the number of pipes, nor should there be any requirement that any pipes be used (ie, no pipes = no alternate dependencies). This should also wotk with bin: and path: type dependencies.

"provides" capability in ports

Use a "provides" key to specify that a port satisfies a particular requirement. Use the name of the port if a provides keyword is not specified. For example, if port able-devel specifies that it provides able then port able-devel would be able satisfy the dependency port:able in another port, without that other port having to be aware of port able-devel

[vinc17@…]

Cc Me!

[raimue@…]

Cc Me!

[macsforever2000@…]

Cc Me!

[blb@…]

Will attach an initial attempt at making the port1|port2|port3 method work. Has seen only limited testing so far.

[blb@…]

diff to base/src/macports1.0/macports.tcl

[blb@…]

diff to base/src/port1.0/portdepends.tcl

[febeling@…]

Cc Me!

[febeling@…]

I was thinking about this the other day, and one workaround I though of was this:

depends_lib port:able

variant baker conflicts charlie {
  depends_lib-delete port:able
  depends_lib-append port:baker
}
variant charlie conflicts baker {
  depends_lib-delete port:able
  depends_lib-append port:charlie
}

One real downside it probably to compile the conflicts lists by hand, which is error-prone. And I haven't tested it. Maybe it doesn't work ;)

[ryandesign@…]

What is the advantage to a "port:a|b|c" syntax? If all these ports provide the same thing, then "path:${prefix}/some/file:a" (where ${prefix}/some/file is a file provided by all three ports) is sufficient, isn't it? We already use this in many places. Anyway, it doesn't solve the problem that each port that depends on, say, a, needs to know that b and c would also work. Most port authors don't take the time to discover this, and also the list of acceptable ports might change over time. For example I might create a -devel port, but then don't really want to have to notify the authors of every port that uses my port to tell them to add the -devel port into their list.

It would be better to do it the second way you suggest, with a "provides" syntax in the port.

[macsforever2000@…]

Replying to ryandesign@macports.org:

What is the advantage to a "port:a|b|c" syntax? If all these ports provide the same thing, then "path:${prefix}/some/file:a" (where ${prefix}/some/file is a file provided by all three ports) is sufficient, isn't it?

Sometimes the dependency requires the entire port, not just a single file. For example, in the bacula port it requires a database be installed (when not using the client-only variant) but it really doesn't matter which precise version it is. To work around this, I had to create variants for each database version which is cumbersome. So instead of creating a variant for postgresql83, postgresql82, postgresql81 AND postgresl80, I decided to only use the latest version. However, it would be better to just have had a "postgresql8" variant which required any of them. The provides keyword would not work in this case.

However, it brings up an issue. If none of the ports are available, which one gets installed? The first one in the list?

I fully agree that the provides keyword is also a great idea. But it seems limited in usefulness to devel type ports only.

[raimue@…]

Replying to macsforever2000@macports.org:

Sometimes the dependency requires the entire port, not just a single file. For example, in the bacula port it requires a database be installed (when not using the client-only variant) but it really doesn't matter which precise version it is. To work around this, I had to create variants for each database version which is cumbersome. So instead of creating a variant for postgresql83, postgresql82, postgresql81 AND postgresl80, I decided to only use the latest version. However, it would be better to just have had a "postgresql8" variant which required any of them. The provides keyword would not work in this case.

So all ports could specify provides postgresql8 as well, but can they be installed at the same time?

We would need some way to express if multiple ports providing the same thing can be installed. For example, python24 and python25 can be installed at the same time, mysql5 and mysql5-devel can not. These are different use cases, maybe we can solve this with only one solution or we need both methods.

However, it brings up an issue. If none of the ports are available, which one gets installed? The first one in the list?

Sounds reasonable.

I fully agree that the provides keyword is also a great idea. But it seems limited in usefulness to devel type ports only.

Just as a note, the OR method requires changing each dependent when adding new ports which would satisfy the dependency.

[ryandesign@…]

It might be easier to discuss this issue on the mailing list instead of in the ticket notes.

[macsforever2000@…]

Actually a few of us had a discussion on the IRC forum about it today. I don't see a problem with using the trac which keeps the discussion conveniently available right here on the ticket.

As another example in favor of allowing OR in dependencies, the meld port requires py25-gtk and py25-gnome. But py-gtk or py26-gtk pr py30-gtk would also work. Same for py25-gnome.

Another topic that came up is that the "provides" keyword could solve the issue of a dependency requiring a variant. The implementation might be a little tricky though. Ideally each variant would automatically create a "provides" token that can then be referenced. For example, py25-scipy requires swig currently. But it really requires swig +python25. So swig with the python25 variant would have an automatic provides "swig+python25" which could then be referenced in py25-scipy.

[blb@…]

Concerning one way vs. the other, a provides-based method would be a better way to go long-term, but I believe this requires quite a few changes throughout base. On the other hand, using | for dependencies has a patch here, now.

[febeling@…]

In my earlier comment I described how we could get Virtual Packages using conflicting variants. The idea is, to spell it out, that the dependent port depends on the virtual port, and that virtual port can be installed using one of several ways, depending on how you specify (mutually exclusive) variants. The variants drive setup a dependency the the implementing port. I think ORed dependencies and Virtual Packages are alternative solutions to the same problem. Virtual Packages have the advantage of hiding "Implementation" (the actual package) behind and "Interface" (virtual package). At least Debian uses this approach as well [1], but I think others as well.

I'm not sure which approach will be better in the long run. And we should probably have only one, not both. But I have tried to implement this as a port group and I find the result quite reasonable, because it does not require changes to the core workings, i.e., not very intrusive, and the resulting "virtual" portfile is short [2], here the postgresql example. And you can list virtual packages, if we put them all into a category "virtual", which is what my patch does. So now we have both options really open for discussion. One disadvantage is that it is very explicit, resulting in portfiles proper, instead of just symbols or names. Which have to be kept current and all. Just have a look. Patch follows.

[1] http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html#s-virtual

[2] http://pastie.org/257239

[febeling@…]

patch for makefile, to install vitual-1.0.tcl as well; apply and run 'sudo make install'

[febeling@…]

Maybe there is an argument for both ORed Dependencies and Virtual Ports.

Virtual Ports: abstract over versions, like the hypothetical "postressql" offering postgresql 7 through 83, and possible packages like mailtranportagent or webserver, satiesfied by a number of implementations.

ORed Dependencies: suppose an application needs an RDBMS, but it can put up with mysql{4,5}, sqlite, postgresql, but not every conceivable RDBMS obviously. So there would a situation where VP does not work but OD does.

So maybe there can be both approaches.