Bug 233360

Summary: [NEW PORT] security/otp: OTP tool
Product: Ports & Packages Reporter: J.R. Oldroyd <fbsd>
Component: Individual Port(s)Assignee: freebsd-ports-bugs (Nobody) <ports-bugs>
Status: Closed Overcome By Events    
Severity: Affects Only Me CC: danfe, w.schwarzenfeld
Priority: --- Keywords: feature, needs-qa
Version: Latest   
Hardware: Any   
OS: Any   
Description Flags
shar of new port security/otp-1
shar of new port security/otp-r136
shar of new port security/otp-r137
shar of new port security/otp-r138 none

Description J.R. Oldroyd 2018-11-20 21:35:20 UTC
Created attachment 199391 [details]
shar of new port security/otp-1
Comment 1 Tobias Kortkamp freebsd_committer 2018-11-21 12:51:07 UTC
XRUN_DEPENDS=	${PREFIX}/bin/gpg:security/gnupg \
X		${PREFIX}/bin/oathtool:security/oath-toolkit \
X		${SITE_PERL}/JSON.pm:converters/p5-JSON

PREFIX is where a port installs into, LOCALBASE is where a ports'
dependencies come from.  So ${LOCALBASE} should be used here.
However we generally just drop ${LOCALBASE}/bin from dependency
specs like this.

XUSE_GNOME=	glib20 gtk30

This is missing USES+=gnome and probably more since otp_gui appears
to be a Perl application.  Is a p5-Gtk3 dependency or similar not
missing too?


I'm sorry but this is not acceptable and won't work in Poudriere
either.  Files need to be checksummed via distinfo and no network
connection is allowed in the extract phase.  Please create a tarball
and use that instead for the port.


This port conflicts with security/heimdal which installs a 'bin/otp'

XFLAVORS=	x11 nox11

Flavors need portmgr approval, so best put it up on
https://reviews.freebsd.org yourself after addressing the above
Comment 2 Tobias Kortkamp freebsd_committer 2018-12-07 12:04:15 UTC
Comment 3 J.R. Oldroyd 2018-12-08 18:17:09 UTC
Created attachment 199964 [details]
shar of new port security/otp-r136

Revised shar file.
Comment 4 Tobias Kortkamp freebsd_committer 2018-12-10 15:28:06 UTC
I have uploaded a cleaned up version to Phabricator for portmgr
review (needed for the flavors bits).

If you have any concerns about the changes I made, please raise
them there if possible.

- I think that overloading do-fetch just for the 'tarball' target
  is too complicated and have moved it to just under 'tarball' which
  is now only defined when you're in port maintainer mode (have
  DEVELOPER defined in make.conf).  The svn:// in MASTER_SITES is
  unlikely to pass a portmgr review (which we need if this is
  supposed to be committed with flavors).

- CONFLICTS* are matching on package names not port origins.

- Can you remove the MimeType line from otp.desktop?  It's empty and
  falsely triggers the USES=desktop-file-utils QA warning.
Comment 5 Tobias Kortkamp freebsd_committer 2018-12-10 16:55:10 UTC
Flavors were rejected.
Comment 6 Tobias Kortkamp freebsd_committer 2018-12-10 16:58:52 UTC
Giving it back to the pool.  I don't have much time or patience to do the
necessary changes.  See the review for some raised problems.
Comment 7 J.R. Oldroyd 2018-12-10 17:26:23 UTC
Several other ports that obtain their source from an svn server overload do-fetch to create the tarball.  I copied the example from those.  Something like 19 of them do it this way!

The Porter's Handbook documents flavors and gives a specific example (sec 7.2) of using "x11 nox11" as the way to add/exclude X11 functionality.  I copied that example.  What is the point of an example in the handbook that is then rejected when we use it???!

I will make the change to the .desktop file.
Comment 8 J.R. Oldroyd 2018-12-10 17:37:19 UTC
Created attachment 200009 [details]
shar of new port security/otp-r137
Comment 9 J.R. Oldroyd 2018-12-29 15:40:10 UTC
Created attachment 200605 [details]
shar of new port security/otp-r138
Comment 10 Walter Schwarzenfeld freebsd_triage 2019-08-08 13:14:35 UTC
Comment 11 Kubilay Kocak freebsd_committer freebsd_triage 2019-08-08 13:18:52 UTC
Comment on attachment 200605 [details]
shar of new port security/otp-r138

Ports not yet in the tree can't (yet) have maintainer approval
Comment 12 J.R. Oldroyd 2019-08-08 14:02:01 UTC
What can I do here?

This port has both a command line and an X11 version.  I did this using flavors and copied how to directly from the Porter's Handbook.  Even so, apparently the flavors were rejected.  What is it that I am expected to do now?

It also overloads do-fetch to pull the files directly from a subversion server rather than use the 1970's technology of tarballs.  Tar files were great for when we exchanged software by means of receiving a magnetic tape at a conference!!  I am prepared to argue elsewhere that we should add subversion fetch support directly to the ports framework.  In the meantime, this do-fetch code works fine.
Comment 13 Alexey Dokuchaev freebsd_committer 2020-07-04 09:37:08 UTC
(In reply to J.R. Oldroyd from comment #12)
> This port has both a command line and an X11 version.
This does not call for flavors.  Simply install both executables/scripts alongside, from one single package.

> It also overloads do-fetch to pull the files directly from a subversion
> server rather than use the 1970's technology of tarballs.
Wrong.  Pulling the code from the VCS is not the right way to distribute software.  From time to time, good developer releases tarballs because downstream package maintainers in various GNU/Linux and *BSD distributions prefer to work with more firmly defined and stable code references.

> In the meantime, this do-fetch code works fine.
It might work, but you should really talk upstream into releasing normal tarballs.  If they don't care or see the need for doing this, then perhaps this software should not be ported and packaged in the first place.
Comment 14 J.R. Oldroyd 2020-07-04 12:07:14 UTC
Wow!  It is 20 months ago that I submitted this.

While I understand that FreeBSD has its standards procedures and arguing for a change when submitting a single new port isn't the way to do it, I am afraid that I do not have the time or interest to resume this discussion at the moment.

The otp tool works fine but I will leave it to others to do a FreeBSD if so desired.