Bug 217176 - security/doas: Port update
Summary: security/doas: Port update
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Joseph Mingrone
Depends on:
Reported: 2017-02-17 15:49 UTC by jsmith
Modified: 2017-02-22 14:58 UTC (History)
1 user (show)

See Also:

Patch to update doas port to match upstream. (1.10 KB, text/plain)
2017-02-17 15:49 UTC, jsmith
jsmith: maintainer-approval+
Updated port patch for doas 6.0p0 (1.09 KB, patch)
2017-02-20 23:13 UTC, jsmith
jsmith: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description jsmith 2017-02-17 15:49:37 UTC
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.
Comment 1 Joseph Mingrone freebsd_committer 2017-02-18 14:19:18 UTC

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.
Comment 2 jsmith 2017-02-18 14:30:28 UTC
I can certainly change the tag on GitHub to match the port for future versions. It makes sense to have them all line up.
Comment 3 Joseph Mingrone freebsd_committer 2017-02-18 15:36:14 UTC
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?
Comment 4 jsmith 2017-02-18 16:43:34 UTC
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.
Comment 5 Joseph Mingrone freebsd_committer 2017-02-20 21:05:22 UTC
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.
Comment 6 jsmith 2017-02-20 23:13:11 UTC
Created attachment 180177 [details]
Updated port patch for doas 6.0p0
Comment 7 jsmith 2017-02-20 23:13:51 UTC
No, I suppose no reason to put it off. I've added the 6.0p0 tag and updated the port to match.
Comment 8 Joseph Mingrone freebsd_committer 2017-02-21 01:26:38 UTC
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.
- 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).

[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?
Comment 9 jsmith 2017-02-21 13:31:26 UTC
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.
Comment 10 Joseph Mingrone freebsd_committer 2017-02-21 14:03:09 UTC
Ah, OK.  It's possible to have multiple LICENSES.

I think the "right" things to do here is


and possibly adding


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).
Comment 11 commit-hook freebsd_committer 2017-02-22 14:54:02 UTC
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

  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

Comment 12 Joseph Mingrone freebsd_committer 2017-02-22 14:57:53 UTC
Thanks.  Committed.