[79340] trunk/dports/net/miniupnpc/Portfile

[Ryan Schmidt]

On Jun 10, 2011, at 01:43, Andrea D'Amore wrote:
> On Fri, Jun 10, 2011 at 2:44 AM, Ryan Schmidt wrote:
>> The epoch is the most significant number for MacPorts when determining if a port is outdated. When MacPorts says that "miniupnpc 1.5_0" is installed, it really means "2_1.5_0" because the epoch is 2. In r79340 you changed it to "0_1.5_1" by removing the epoch line and adding the revision.
>> MacPorts sees "0_1.5_1" as less than "2_1.5_0" so it will not present your update to the user in "port outdated".
> 
> That's actually false, I tested before committing and just ran the
> test again to confirm: decreasing epoch, increasing revision and
> running portindex shows a port as outdated.
> 
> Test:
> 
> dports $ port installed miniupnpc
> The following ports are currently installed:
>  miniupnpc @1.5_2 (active)
> dports $ grep "revision\|version\|epoch" $(port dir miniupnpc)/Portfile
> version             1.5
> revision            2
> epoch               2
> dports $ portindex >/dev/null; port outdated
> No installed ports are outdated.
> dports $ #editing portfile
> dports $ grep "revision\|version\|epoch" $(port dir miniupnpc)/Portfile
> version             1.5
> revision            3
> epoch               1
> dports $ portindex >/dev/null; port outdated
> The following installed ports are outdated:
> miniupnpc                      1.5_2 < 1.5_3
> dports $
> 
> 
>> In r79342 I've put back the epoch line so now it's "2_1.5_1" which is indeed greater than "2_1.5_0" and thus will be presented to the user as an available upgrade.
> 
> Actually the epoch didn't make any sense because current target is 1.5
> tarball and mastersite offers both 1.5.tar.gz abd a newer
> 1.5.20110527.tar.gz, if epoch had to be set at all it had to be
> 20110527, as it was upgrading fine without epoch I decided to remove
> it.

We have always said, and will always continue to say, that the epoch line, once added to a port, can never be removed. It is the exclusive reason why the epoch property exists in the first place: to enable "upgrades" to versions which wouldn't otherwise appear to MacPorts to be upgrades. The reason the epoch was added to this port in r79142 is that the port was at version 1.5.20110527 but David wanted to "upgrade" the port back to version 1.5, which MacPorts would otherwise have considered to be less. (According to the commit message, 1.5.20110527 is apparently a development version, not a stable version.)

Possibly, your transcript above demonstrates a bug in epoch handling when only the epoch and revision, and not the version, are changed. I haven't tried to reproduce it yet. However you cannot guarantee that all of the users that had previously installed version 1.5.20110527 had already upgraded to epoch 2 version 1.5. Therefore you cannot remove the epoch.

It makes absolutely no difference whether the epoch is set to 2 or 500 or 20110527; all that matters is that it is an integer that never decreases.