version dependencies in MacPorts?

[Jack Howarth]

On Sun, Sep 13, 2009 at 10:41:38PM +0200, Rainer Müller wrote:
> On 2009-09-13 21:30 , Jack Howarth wrote:
> >    It certainly would be nice to have some sort of basic
> > version/revision tracker for at least the buiild process of
> > MacPort.
> 
> Of course I do not disagree that dependencies with versions would be
> useful. :-)
> 
> My proposal would be to add the version to existing dependencies, like
> port:foo@>=1.0 with possible operators being <, >, <=, >= and =. If no
> version is specified, the current rules apply that the latest version is
> necessary.
> 
> But before we could do something like this, we would also need a better
> syntax to handle multiple choices (like for *-devel ports) as this would
> not be possible with path: or bin: dependencies.
> 
> > In fink, the incrementation of package names (foobar,
> > foobar2,foobar3) is reserved for the case where the ABI and
> > major soversion number changes (such as openmotif3 for 2.2.4
> > and openmotif4 for 2.3.2). Implementing such version tracking
> > in the packaging building side would probably easier to
> > than at the installation side (when only binary packages are
> > present) but still provide the framework for adding that at
> > a later date.
> 
> I see the problem in keeping these dependencies updated, as it is hard
> already to maintain basic dependencies with just port names. Finding out
> which versions are supported can be hard for some ports if it is not
> noted down in INSTALL or README.
> 
> We do not have a written down strict policy for port names, but in my
> opinion foobar should always be the latest available version. Ports like
> foobarX should only be created if another dependent port cannot work
> with the new version due to major API changes.
> 
> Rainer

Rainer,
   I am not so much concerned about the installation dependencies but
more on the build dependencies. For instance, I would often want to
increase the minimum required version of gmp or libmpfr1 for the gcc4x
packages. Rather than depending on users having executed selfupdates
in a sequence that ended up those packages being updated before gcc4x
was built, it is better for the build of gcc4x to be able to demand
the newer versions/revisions being installed before the gcc4x package
could be built. It definitely reduces the support issues for the
distribution when there is some certainty of which versions of
support libraries a package is built against. In the case of gcc45,
configure will throw an error if the correct version of cloog-ppl isn't
installed but relying on that isn't the best solution.
          Jack