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

[Joshua Root]

On 2012-4-13 13:40 , Eric Cronin wrote:
> On Apr 12, 2012, at 11:19 PM, Joshua Root wrote:
>> On 2012-4-13 04:47 , Eric Cronin wrote:
>>> 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...

I see your point, but revision is still the right tool for the job.
Often the newer version isn't intrinsically broken, it's just that
dependents haven't been updated to be compatible with it yet. See the
recent case of goffice.

If it is intrinsically broken, that would mean that for that exact
version to appear again in the future, it must be fixable with a patch.
In that case, it's probably better to patch it than to revert.

There still may be cases where it's better to revert now and figure out
the patch later, but in that case, what we really want is a way to
delete archives that are known to be broken. An easy DIY method would be
nice, but asking Bill to do it is always an option.

Projects resetting their versioning is an awful degenerate case that is
probably best handled by using a new port name.

- Josh