> 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.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
