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

[Ryan Schmidt]

On Sep 30, 2014, at 7:26 PM, Sean Farley wrote:
> 
> Ryan Schmidt writes:
> 
>> On Sep 30, 2014, at 4:55 PM, Sean Farley wrote:
>> 
>>> As for this exact issue, it could be something as simple as a fallback
>>> test:
>>> 
>>> if checksum doesn't match and revision is new:
>>> try downloading again
>>> write state so we don't download in an infinite loop
>> 
>> That's a conceivable change. But let's look at what problems that particular change would involve:
>> 
>> * MacPorts would need to gain the capability to go back to a previous phase (fetch) after it has already been completed. Or perhaps simpler, MacPorts would need the ability to automatically clean a port and try it from the beginning based on some criteria. This would be quite useful for a number of issues MacPorts users currently experience, but it's not a capability that exists today.
> 
> This is a very real issue. Difficult to do in today's code base.
> 
>> * 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?


> 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.


>> * 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.