Record TIMESTAMP in `make makesum`

[emaste]

Summary

For future reproducible builds support record the timestamp when 'make makesum' updates the distinfo.

This change is extracted from D4385 so that we can start recording this as ports are otherwise updated.

[emaste]

That should be "extracted from D4385 and modified slightly"

[bdrewery]

The code seems fine but this line will be problematic unless explained very well. For example in security/openssh-portable every time I update its major version I run 'make makesum' and it removes all of the optional patches. I then re-add the optional patches and one-by-one manually update the distinfo for them and test since they are conflicting and cannot all build together. Often I have to mark an option broken for days/weeks while I fix it or wait for the patch upstream to release an updated version. I'm sure other people have similar experiences. In this case I would likely forget to touch the TIMESTAMP or consider it out-of-scope.

I think a $FreeBSD$ keyword comment at the top would be more accurate as it will capture all changes. If someone runs 'make makesum' and the file doesn't change then the comment also will not change and keep the existing timestamp. In this case we would just use the revision in the comment and not the date.

[emaste]

In D6031#128734, @bdrewery wrote:

The code seems fine but this line will be problematic unless explained very well. For example in security/openssh-portable every time I update its major version I run 'make makesum' and it removes all of the optional patches. I then re-add the optional patches and one-by-one manually update the distinfo for them and test since they are conflicting and cannot all build together. Often I have to mark an option broken for days/weeks while I fix it or wait for the patch upstream to release an updated version. I'm sure other people have similar experiences. In this case I would likely forget to touch the TIMESTAMP or consider it out-of-scope.

The intended use of the timestamp here is to control the metadata for files in the package, and I think it's not a problem if it updates only when the main source files change.

I think a $FreeBSD$ keyword comment at the top would be more accurate as it will capture all changes. If someone runs 'make makesum' and the file doesn't change then the comment also will not change and keep the existing timestamp. In this case we would just use the revision in the comment and not the date.

The date from $FreeBSD$ seems like a good idea, except it's not expanded in ports git mirrors and so might introduce subtle breakage in some cases.

[bapt]

In D6031#128739, @emaste wrote:

In D6031#128734, @bdrewery wrote:

The code seems fine but this line will be problematic unless explained very well. For example in security/openssh-portable every time I update its major version I run 'make makesum' and it removes all of the optional patches. I then re-add the optional patches and one-by-one manually update the distinfo for them and test since they are conflicting and cannot all build together. Often I have to mark an option broken for days/weeks while I fix it or wait for the patch upstream to release an updated version. I'm sure other people have similar experiences. In this case I would likely forget to touch the TIMESTAMP or consider it out-of-scope.

The intended use of the timestamp here is to control the metadata for files in the package, and I think it's not a problem if it updates only when the main source files change.

I think a $FreeBSD$ keyword comment at the top would be more accurate as it will capture all changes. If someone runs 'make makesum' and the file doesn't change then the comment also will not change and keep the existing timestamp. In this case we would just use the revision in the comment and not the date.

The date from $FreeBSD$ seems like a good idea, except it's not expanded in ports git mirrors and so might introduce subtle breakage in some cases.

The goal of this date is to not be updated to often but still often enough so that it is at least as old as the main sources

[bdrewery]

I think this will be error-prone to keeping it consistent but I don't really object to trying.