[76912] trunk/dports/devel/bzr-svn

Rainer Müller raimue at macports.org
Sat Mar 12 15:12:57 PST 2011

On 2011-03-12 23:53 , Ryan Schmidt wrote:
>>> We should probably continue to try to keep the epoch line *above*
>>> the version line, since it has a *higher* precedence for MacPorts
>>> than the version or revision. Placing it below the version line
>>> gives it the impression of having a lower precedence and inviting
>>> a future contributor to believe the epoch line can or should be
>>> removed when increasing the version, which is not correct.

Makes sense, done so in r76918.

> Also, consider that there are ports that set their version based on
> other variables, for example based on ${svn.revision}. I don't
> personally like it when ports do that -- I like the version field to
> be the definitive source of the version, and to base any calculations
> off of that, not the other way around -- but that's up to the
> maintainers to decide for themselves. Having to shove calculations
> like these into a line that already includes epoch and revision
> information would probably make it less readable.

Splitting options is not the way we usually do it. For example, we set
distname and extract.suffix which influence distfiles. We do not set
distfiles and split distname and extract.suffix out afterwards.

Often a concatenation in the version field would be much easier to
understand than splitting up version into svn.revision using nested
split/lrange/join commands.


More information about the macports-dev mailing list