[123602] trunk/dports/python/py-astropy/Portfile

[Sean Farley]

Ryan Schmidt writes:

>>> * It assumes the port's revision will be increased. That's not always necessary. Sometimes the only change in the distfile is the name of (or presence of) the enclosing directory, or there are only changes in comments or documentation files or other files that don't affect the build, and in those cases there would be zero benefit to increasing the port's revision and forcing everyone to rebuild or redownload.
>> 
>> That's true. In this case, we should borrow an idea from DVCSes: use a
>> hash to see if something has changed (probably something like a Merkle
>> tree).
>
> I'm not familiar with a Merkle tree. I skimmed the wikipedia page but I'm not sure what you're suggesting here. What should be hashed, by whom, at what time?

It's just a fancy way to help detect if a tree has changed. Might not be
helpful here, exactly.

>> This would be a nontrivial amount of work but would help mitigate
>> the whole 'epoch' business.
>
> I don't see what the epoch field has to do with this discussion at all.

It's an orthogonal discussion which I'll save for another time.

>>> * The old distfile would get removed from our mirrors, making it impossible for anyone to later determine what exactly changed in the stealth update. Many maintainers handle stealth updates incorrectly. It is nice for others to be able to investigate after the fact.
>> 
>> If we used hashes in the distfile naming, we wouldn't be overwriting
>> things.
>
> Ok, that's another good suggestion. I've seen that approach used by debian which puts each distfile in a directory whose name is the hash of the distfile.
>
> ~
>
>
> Let me just once again make sure that I understand the situation that we're discussing here. Here are the facts as I understand them. Let me know if I've misunderstood our goal in this discussion or if there are any other aspects.
>
>
> 1. It is the maintainer's responsibility to notice when a stealth update has occurred.
>
> 2. It is the maintainer's responsibility to obtain the new distfile and place its new checksums into the portfile, after verifying that the new distfile is correct and is not malicious.
>
> 3. It is the maintainer's responsibility to decide whether this change requires users to rebuild their ports, and on the basis of this determination to increase the port's revision or not.
>
> 4. It is considered too onerous for the maintainer to need to insert the line "dist_subdir ${name}/${version}_1" into the portfile when a stealth update occurs, and we would like to make this step unnecessary.

That sounds right. What I'm attempting to improve (or, rather, stir up
awareness) are the many steps that are manual. Being that stealth
updates are infrequent, I usually forgot to check for them. I think 

A workflow I am trying to strive for (which maybe should be another email):

Task: update outdated ports

$ port echo maintainer:sean | parallel --trim lr port livecheck {}
mercurial seems to have been updated (port version: 3.0, new version: 3.1)

$ port maintainerupdate mercurial
  # this would replace the previous version string with the new one and
  # accept the checksum changes

$ hg ci -m "mercurial: update to 3.1"
$ hg push try-server

# this is where a buildbot would test the change and tell me a few
# common issues:
#   - was there a stealth update
#   - did I "Use The Right Compiler"
#   - run "port test" (or something similar)

If all the tests pass (and perhaps all the dependent ports pass) then it
would be allowed to be pushed to the central repository.