Citando Rainer Müller :
Emmanuel Hainry wrote:
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.
Why? I just don't get this point.
I know the ports I maintain build with the latest versions of their dependencies at the time I uploaded the Portfile. I am unable to predict breakage (for example when libogg changed its API, mpd did not build anymore) and I am even more unable to decide if it builds against each version of each of its dependencies. The current way is tractable for me, adding such possibility would mean far more testing than trying to build the port with the differents combinations of variants. If the other maintainers have far more free time than I do, maybe it can work and the tree will not be full of untested dependencies. Seeing the number of unmaintained ports, and the numbers of tickets in trac (even simple updates), I would say that it is not the case.
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.
Okay, let's call it "metaport". But it is the same thing you are describing.
Yes, I just stated that it was the part of what you proposed I found interesting: as long as it is not taken too far.
A port which provides multiple versions of a software. Nevertheless, dependencies have to go in each version of a port. A development snapshot could have completely different dependencies than the current "stable" version.
Yes of course. The metaport metaphp would depend on php5 or php52 or any version. But those ports keep their current portfile. Then ports depending on "just any version of php" would put depends-lib metaphp in their portfile. Emmanuel