[91865] trunk/dports/science/netcdf-cxx/Portfile

[Eric Cronin]

On Apr 12, 2012, at 11:19 PM, Joshua Root wrote:
> On 2012-4-13 04:47 , Eric Cronin wrote:
>> On 12.04.2012 10:34, Joshua Root wrote:
>>> On 2012-4-13 00:20 , Jeremy Lavergne wrote:
>>>> When the epoch gets put back in, you'll also need to update the
>>>> revision.
>>>> epoch: 1
>>>> version: 4.2
>>>> revision: 2
>>> 
>>> The bug in the registry API that necessitates that is gone in 2.1 BTW.
>>> 
>> 
>> Wasn't there a second issue that the filenames for packages don't
>> include epoch, so there is a risk of grabbing/reusing the package from a
>> different epoch if the version_revision part happens to match?  Is this
>> fixed as well in 2.1?  None of the packages on packages.macports.org
>> have epochs in the filenames yet.
> 
> It doesn't matter, by definition. A higher epoch just tells you that an
> older-looking (but different) version is actually newer. If
> name,version,revision,variants are all the same, it's the same software.
> 
> This means you can upgrade a port from 1.0 to 1.1, and then if there are
> problems with 1.1, revert to 1.0 by increasing the epoch, and nobody who
> hadn't upgraded yet has to rebuild.

Going backwards it's not a problem because you'd usually be using svn to actually revert to the previous version of the Portfile and make the one line change to increment epoch.  But doing that leaves an epoch 0 version of 1.1_0 hanging around.  What happens if the Portfile continues to evolve on the 1.0 epoch 1 branch until some time in the future it hits 1.1_0 again but on epoch 1?  The epoch 0 and epoch 1 Portfiles for 1.1_0 won't be identical and will be producing different packages (1.0 to 2.0 back to 1.0 followed by 1.1, 1.2, and then, after we've forgotten about the whole reversion having happened, 2.0 a second time would be a better example of how 2.0_0 epoch 0 and 2.0_0 epoch 1 could be very different software.)...  And then there are the occasional projects which reset their version numbering themselves.

I guess the answer to my question is that this is still (intentionally, to save rebuilding on quick reverts) an issue, and you need to comment the Portfile after reverting that certain future version_revisions need to be avoided...

Thanks,
Eric