Citando Rainer Müller :
Ryan Schmidt wrote:
For what purpose? We already have the situation that when we want to make, say, both apache 2.0 and apache 2.2 available, we create two ports: apache20 and apache2, respectively. This works fine. What do you need in addition to that?
One could choose which version to install without loosing dependencies. For example, all of our *-devel ports are useless because they break the depedencies. For example, you can't install something like apache2-devel and add php5, because php5 depends on the normal apache2.
With multiple version per port this would be possible. But it would also require the introduction of new commands that allow a port to depend on at least a specific version of another port.
We could mark the different versions as "stable" or "unstable". With this approach we would get a better environment to test port upgrades with beta versions or release candidates.
Being a simple maintainer, I would say that dependencies on specific version (à la debian "this software require thingy version > 2.2.17 but it is not going to be installed") would make me unable to manage seriously my ports. The not too untractable point however would be to introduce some metaports (for example, musicpd can be provided by mpd or mpd-dev), and dependencies would be put to the metaport instead of one of the providing ports. It can at the moment be achieved through the old dependency scheme (sthg like depends_lib bin:mpd:mpd-devel) but that scheme cannot discriminate between something provided by macports and something provided by apple or another source. Emmanuel