about keeping a checksums table in a separate file

[Marius Schamschula]

I use a short python script to automatically update most checksums.

However, even the small number of ports I maintain (OK there 69 of them) and the no maintainer/slowmaintainer ports that I version bump from time to time, I have found a dozen that have multiple sets of checksums, e.g. bash that has a separate checksum for each patch, etc. For those, I just manually update the checksums.

On Feb 1, 2016, at 3:45 PM, Daniel J. Luke <dluke at geeklair.net> wrote:

> On Feb 1, 2016, at 4:36 PM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
>> How likely is it that two files would have the same oldchecksum
> 
> not very
> 
>> but a different newchecksum? Probably very small for sha256, but the shorter the hash, the larger that likelihood. That still won't be an issue for most ports that only have checksums for a single file. Still, you'd probably want to know all old checksums of all (old) distfiles, and the corresponding new ones to check for aliasing before you start replacing.
> 
> sure.
> 
> I'd be willing to wager we've never had a hash collision, though.
> 
>> A better non-trivial example than my KF5 Frameworks Portfile would be mcalhoun's port:qt5 Portfile. I'm not sure you need to connect the checksums with the distfile/subport in the Portfile (as opposed to in memory only), but that would probably be a challenge for this kind of coding.
> 
> I would advocate a "worse is better" approach here.
> 
> A very simple substitution intended for a maintainer to run, something like `port checksum --stage-update foo` that can then be verified and committed.
> 
> Maybe this doesn't work (or doesn't work well) for complicated portfiles - but if it's a 90% solution that covers mosts ports, it's still a win (and if it enables people to write less complicated portfiles, since they were just trying to make it easier to update their ports, that's a win too).
> 
> In fact, I would propose that the existence of complicated portfiles is evidence of features in base that are missing that maintainers desire.
> 
> -- 
> Daniel J. Luke
> 

Marius
--
Marius Schamschula




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160201/5f40f29e/attachment-0001.html>