Created attachment 180080 [details] Patch to update doas port to match upstream. The attached patch updates the FreeBSD port of security/doas to match the upstream version on GitHub. The new version, 6.0-0, includes code reorganization and minor changes which reflect the OpenBSD version of doas. This new version also runs on DragonFlyBSD and adds documentation edits to better reflect how doas works on FreeBSD.
Hi, This looks good. If it does not cause much trouble elsewhere, would you consider making the release tag on GitHub match PORTVERSION? That is, the tag for commit fb1108b would be 6.0p0. This will simplify the port a little and make the port work well with tools like portscout.freebsd.org.
I can certainly change the tag on GitHub to match the port for future versions. It makes sense to have them all line up.
I notice in the LICENSE file that the copyright is still for 2016. Do you want to update that? Regarding the tag, basing the port on a proper upstream release in preferable to grabbing a commit. Releases are intended as such. Your current tag has a '-' in the name, so we can't base the PORTVERSION on that without hackery. In this case it isn't so bad since you control the upstream repository and maintain the port (it's not just an arbitrary commit, but you intend for it to be a release). Is there a compelling reason not to fix the release tag for this port update?
Since the bulk of the code in this release was published in 2016, I think the copyright makes sense. The next update (probably in May) will carry the new 2017 date. There is no reason for a commit over a tag or for the tag having a dash in it, other than that was an easy way to do things at the time. We can definitely use different tags in the future.
Is there a compelling reason not to create a 6.0p0 tag for _this port update_? You don't even have to delete the other v6.0-0 tag.
Created attachment 180177 [details] Updated port patch for doas 6.0p0
No, I suppose no reason to put it off. I've added the 6.0p0 tag and updated the port to match.
I am about ready to sign off on https://reviews.freebsd.org/D9664. - There is no need for GH_TAGNAME when PORTVERSION matches the GH release tag. Nitpicking: - RE: ETCIDR: No need to create a new variable that is only used once. - Minor alignment changes (which don't show up properly in Phabricator). - Set LICENSE_FILE [1]. [1] My understanding is that adding a license file to a code repository has no effect on licensing; it's the license declarations in each source file that matter. (This raises questions about the ports licensing framework.) However, creating a new LICENSE file that includes a different license from that in the source files and removing the original author's copyright notice might be asking for trouble. I will leave this as a question for you and I won't insist either way. What do you think about updating the LICENSE file to use the same license as in the source code and adding your copyright notice along with the original author's?
Regarding the license, the reason for the difference between the LICENSE file and some of the source file headers is some of the code comes from OpenBSD and some comes from the NetBSD port. The license in the LICENSE file came in as part of the NetBSD patches. You can see they match if you look at the execvpe.c file. I'm not sure if we can legally change the license file to match OpenBSD upstream as that would require stripping away the licensing terms added by the NetBSD developer. As for the ETCDIR and GH_TAGNAME variables, I don't have strong feelings about how this is done either way. But the handbook seems to suggest these variables should be specified this way. The tagname defaults to three combined variables, according to the handbook which is why it's declared explicitly here. If that's not required I'm fine with dropping it.
Ah, OK. It's possible to have multiple LICENSES. I think the "right" things to do here is LICENSE= BSD2CLAUSE ISCL LICENSE_COMB= multi and possibly adding LICENSE_FILE_BSD2CLAUSE=... LICENSE_FILE_ISCL... I might be unnecessarily dragging this out, but it would be good to get this correct and not have to worry about it in the future. Let me try and get a second opinion (if anyone will be willing to touch this unpleasant license stuff).
A commit references this bug: Author: jrm Date: Wed Feb 22 14:52:56 UTC 2017 New revision: 434585 URL: https://svnweb.freebsd.org/changeset/ports/434585 Log: security/doas: Update to version 6.0p. - Pull tarball from a GitHub release rather than a commit. - Update license information. There is code under BSD2CLAUSE and code under ISCL. PR: 217176 Submitted by: jsmith@resonatingmedia.com (maintainer) Approved by: mat, swills (mentor, implicit) Differential Revision: https://reviews.freebsd.org/D9664 Changes: head/security/doas/Makefile head/security/doas/distinfo head/security/doas/files/pkg-message.in
Thanks. Committed.