Split Trunk

[Emmanuel Hainry]

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