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

[Ryan Schmidt]

> On Sep 30, 2014, at 8:55 PM, Sean Farley wrote:
> 
> 
> 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)

For this I use my portmylivecheck script:

https://svn.macports.org/repository/macports/users/ryandesign/scripts/

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

For this I use my portcheckup script:

https://svn.macports.org/repository/macports/users/ryandesign/scripts/

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

If you're suggesting this just as a personal workflow for you, ok. But if you're suggesting this would be an infrastructure available to everyone, then we're either back at the old discussion of switching the MacPorts repository from Subversion to git or mercurial or something else, which we agreed before was too much effort, or we're talking about introducing a second version control system into the mix somehow, which sounds really confusing to me.


> # this is where a buildbot would test the change and tell me a few
> # common issues:
> #   - was there a stealth update

We could perhaps enhance the buildbot scripts to re-fetch the upstream distfile every time you commit the port and to let you know if its checksums no longer match those in the portfile. But if so, only a human can determine if that was because of a stealth update or because of something else. It feels like this would be a waste of bandwidth and server resources, however.

> #   - did I "Use The Right Compiler"

You can of course use the setup documented at the bottom of the UsingTheRightCompiler wiki page to determine this on your local machine prior to committing.

If you're wanting the buildbot to automate testing this for you, then I suppose instead of the current placeholder script that prints an error and exits (which can sometimes be missed because the output is discarded or hidden on a config.log or other log file), we could have the placeholder script create a log file of its own, followed by actually invoking the compiler so that the build succeeds anyway, then do something with the logfile later.

> #   - run "port test" (or something similar)

Yup, we've discussed previously that it would be nice if tests could be automatically run, however many ports' tests do currently fail, and some others take a very very very long time.


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