about keeping a checksums table in a separate file

[René J.V. Bertin]

On Monday February 01 2016 16:31:59 Marius Schamschula wrote:

> > - portfile is extra complicated (does some craziness to generate a large number sub-ports)
> 
> Yup. Like mysql*, php, etc.
> 
> Then there are ports like sqlite3 that use a non-standard versioning scheme for the distfile, which causes my current script to fail.

That might be less of an issue if the feature is implemented in "base" itself. You wouldn't have to guess the distfile name(s), it'd be available through ${distfiles}, and the corresponding checksum(s) through ${checksums}. Then you should indeed be able to do what I suggested earlier:
- calculate the new checksums
- determine and check all old checksums; if there are cases of aliasing (several files having the same checksum), just print the new checksums and abort. Possibly over-careful, but so simple it shouldn't cost anything to add as a failsafe. Same if the old checksums cannot be determined for each distfile. NB: this kind of aliasing would only be a problem for brute search/replace operations, so I doubt there's ever been reason to pay attention to its possible occurrence.
- for each old,new checksum pair, do a whole-pattern search and replace of oldchecksum with newchecksum in the entire file.

Determining the name of the old distfile(s) is still going to be an issue, but maybe there could be a special variable for the old version, to be used only by a port maintainer when upgrading a port and not to be present otherwise:

previous_version 	1.0
version				1.1

with that, the algorithm ought to be able to reconstruct the old distfile name by replacing ${version} with ${previous_version} ... but even that only works for distfiles that have the full version in their name. At least that gives a few more conditions that have to be met (and can be evaluated) for the feature to be applicable.

R.