Port development status

Rainer Müller raimue at macports.org
Sat May 23 06:57:22 PDT 2015


On 2015-05-22 15:17, René J.V. Bertin wrote:
> On Friday May 22 2015 14:36:49 Rainer Müller wrote:
> 
>> What if a port flagged "stable" depends on an "unstable" port?
> 
> That'd be an anomaly and in order for anything like this to function
> with MacPorts, base would have to support the notion of depending on
> specific versions. Debian's systems allows to indicate that a
> dependency has to be more (or less!) recent than a certain version,
> and can do the same with conflicts ("breaks foo < Y").

So you assume we provide multiple versions of the same port? Adding such
a flag in the current state does not make sense. Any port could switch
from stable to unstable at any time, breaking the dependency chain.

I remember earlier discussions on this topic. There would be two ways to
provide multiple stable/unstable versions:

a) provide stable and unstable ports trees (Debian way)
b) provide multiple versions of the same port,
   marking one as default/stable (Gentoo way)

The first approach with testing/stable ports trees does not fit the
development of MacPorts in my opinion. We are not following any fixed
release plan. Also, who would decide when to migrate from testing to
stable? Who would check for possible portability problems? Looking at
the fragile state of the current buildbot infrastructure, running
automated tests for several combinations does not seem feasible.

The second approach with multiple versions per port would allow to add
new versions without forcing everyone to upgrade immediately. This opens
the possibility to test new versions with a few brave testers without
the need to add and remove custom repositories to sources.conf all the
time. Basically, I think this would reflect the status flag that spun
off this thread.

However, previously both of these possible ways were ruled out because
the additional overhead for the maintainers did not seem worth the effort.

Rainer


More information about the macports-dev mailing list