Bug 211578

Summary: Some ports specify libpcap ambiguously
Product: Ports & Packages Reporter: John Marino <marino>
Component: Individual Port(s)Assignee: John Marino <marino>
Status: Closed FIXED    
Severity: Affects Some People CC: garga, koobs, pi
Priority: --- Flags: koobs: maintainer-feedback+
Version: Latest   
Hardware: Any   
OS: Any   

Description John Marino freebsd_committer 2016-08-04 13:45:27 UTC
There are currently 10 ports that have specified a library dependency on net/libpcap ambiguously.  This specification is satisfied by the base libpcap library, so the specification has no effect.

I can't tell what the port maintainer intends with regard to libpcap.

If the maintainer intends to use the base libpcap, the specification should be removed (all platforms have libpcap so specification is never satisfied).

If the maintainer intends that the ports libpcap be used, it needs to be specified as "LIB_DEPENDS= libpcap.so.1:net/libpcap", not "LIB_DEPENDS= libpcap.so:net/libpcap"

Can everyone here indicate their intent? Or even commit the fix to their port and reference this PR number?

Thanks!
John

net/daq (zi) (LIB_DEPENDS, intent unclear)
net/hexinject (sbz) (LIB_DEPENDS, intent unclear)
net/libtrace (matt@peterson.org)  (LIB_DEPENDS, intent unclear)
net/tcpdump (garga) (LIB_DEPENDS, intent unclear)
net/xorp (hrs) (LIB_DEPENDS, intent unclear)
net-mgmt/netams (jura@netams.com) (LIB_DEPENDS, intent unclear)
net-mgmt/yaf (dikshie@sfc.wide.ad.jp)  (LIB_DEPENDS, intent unclear)
security/barnyard2 (bofh) (non-default option, mis-specified)
security/py-crits (dvl) (LIB_DEPENDS, intent unclear)
security/suricata (koobs) (non-default option, mis-specified)
Comment 1 commit-hook freebsd_committer 2016-08-04 14:19:00 UTC
A commit references this bug:

Author: marino
Date: Thu Aug  4 14:18:33 UTC 2016
New revision: 419614
URL: https://svnweb.freebsd.org/changeset/ports/419614

Log:
  net-mgmt/netams: reset maintainer, expire, make less broken

  First, the port already has 3 maintainer timeouts going back years, so
  go ahead and reset maintainership.

  Second, it's broken on FreeBSD 10 and newer.

  Third, the options were broken (e.g. USES defined after <options>,
  <pre> and <post> also used with options.  I tweaked this some (untested)

  Fourth: The pcap specification is ambiguous.  (I removed it). [1]

  The entire port is in really bad shape so set it for removal in
  two weeks.

  PR:	211578 [1]

Changes:
  head/net-mgmt/netams/Makefile
Comment 2 John Marino freebsd_committer 2016-08-04 16:21:21 UTC
pi@, you might be able to answer net-mgmt/yaf, it was your commit that added the pcap requirement back in March:

https://svnweb.freebsd.org/ports/head/net-mgmt/yaf/Makefile?r1=410459&r2=410460 (upgrading 2.8.0 => 2.8.1)
Comment 3 commit-hook freebsd_committer 2016-08-04 16:26:24 UTC
A commit references this bug:

Author: bofh
Date: Thu Aug  4 16:25:53 UTC 2016
New revision: 419628
URL: https://svnweb.freebsd.org/changeset/ports/419628

Log:
  security/barnyard2: Fix ambiguous specification of libpcap

  PR:		211578
  Submitted by:	marino

Changes:
  head/security/barnyard2/Makefile
Comment 4 John Marino freebsd_committer 2016-08-04 16:44:16 UTC
Thanks Muhammad,
I'm going to remove people from the CC list as their related ports get fixed to avoid spamming everyone unnecessarily.
Comment 5 commit-hook freebsd_committer 2016-08-04 16:52:29 UTC
A commit references this bug:

Author: marino
Date: Thu Aug  4 16:52:00 UTC 2016
New revision: 419630
URL: https://svnweb.freebsd.org/changeset/ports/419630

Log:
  net/libtrace: Fix LIB_DEPENDS on pcap (ports version desired)

  The configure argument makes it clear the ports version of libpcap is
  desired, but due to the ambiguous specification, the dependency was
  never registered, but this commit rectifies that issue.

  PR:		211578
  approved by:	just-fix-it

Changes:
  head/net/libtrace/Makefile
Comment 6 Ryan Steinmetz freebsd_committer freebsd_triage 2016-08-04 17:57:23 UTC
These dependencies exist to enable Endace DAG functionality in our various ports.  Since DAG support is off by default in libpcap (and requires external libraries), removing the port version of libpcap from the DEPENDS list on all of these ports will break this for Endace users.

Please revert and leave it as it was.
Comment 7 Ryan Steinmetz freebsd_committer freebsd_triage 2016-08-04 18:04:26 UTC
I'm guessing that cdpsnarf users would probably not need to use it on their Endace cards, however, up to you.
Comment 8 commit-hook freebsd_committer 2016-08-04 18:14:48 UTC
A commit references this bug:

Author: sbz
Date: Thu Aug  4 18:14:31 UTC 2016
New revision: 419643
URL: https://svnweb.freebsd.org/changeset/ports/419643

Log:
  - Fix ambiguous specification of libpcap by using libpcap from base
  - Regenerate patch using make makepatch
  - Make happy portlint

  PR:	211578
  Submitted by:	marino

Changes:
  head/net/hexinject/Makefile
  head/net/hexinject/distinfo
  head/net/hexinject/files/patch-prettypacket.h
Comment 9 John Marino freebsd_committer 2016-08-04 18:31:09 UTC
(In reply to Ryan Steinmetz from comment #6)
Ryan, I think you have misunderstood this PR.
Take daq as an example.  You just said daq is supposed to pull in ports libpcap.  That's fine, but that's not what is happening.

Thus, daq port has a bug in it.  You want libpcap, but you aren't getting it because LIB_DEPENDS is badly specified and it's pulling in base libpcap instead (the opposite of what you want).

What exactly is it that you think needs reverting?  nothing has been committed yet.  This a per-port decision which is why the PR was opened.  THe only commits have happened on ports where a decision has been made.

Is that clear now?
Comment 10 John Marino freebsd_committer 2016-08-04 18:34:54 UTC
(In reply to Ryan Steinmetz from comment #7)
Kurt already fixed cdpsnarf by choosing to continue to build it was base libpcap as it has been building since the beginning of the port.  I didn't touch it.
Comment 11 John Marino freebsd_committer 2016-08-04 18:37:44 UTC
i guess you said DAG not "daq" but my general point stands.  Each maintainer has to decide explicitly decide if the want ports pcap or not.
Comment 12 commit-hook freebsd_committer 2016-08-04 18:49:58 UTC
A commit references this bug:

Author: garga
Date: Thu Aug  4 18:49:48 UTC 2016
New revision: 419648
URL: https://svnweb.freebsd.org/changeset/ports/419648

Log:
  - Update net/tcpdump to 4.8.0
  - Fix ambiguous specification of libpcap by using libpcap from base [1]

  PR:		211578 [1]
  Sponsored by:	Rubicon Communications (Netgate)

Changes:
  head/net/tcpdump/Makefile
  head/net/tcpdump/distinfo
Comment 13 John Marino freebsd_committer 2016-08-05 12:06:20 UTC
garga, this is related to your libpcap upgrade commit.  Apparently it broke in the case of IPv6 option is off.  I'm being told the following patch for DF should be applicable to FreeBSD as well:

https://github.com/DragonFlyBSD/DeltaPorts/pull/602
Comment 14 John Marino freebsd_committer 2016-08-05 12:15:55 UTC
4 of the five remaining belong to ports committers:

net/daq (zi) 
net/xorp (hrs) 
net-mgmt/yaf (dikshie@sfc.wide.ad.jp) (libpcap introduced by pi)
security/py-crits (dvl) 
security/suricata (koobs) 

All you have to do is say either "the port should be using base libpcap" or "the port should be using libpcap from ports".  I will do the actual commit if you want, but I need direction.

To recap: None of those ports use libpcap from ports, but it's likely that it was intended that some or all of them do.
Comment 15 John Marino freebsd_committer 2016-08-05 12:22:54 UTC
regarding py-crits, somebody gave me a patch for the RUN_DEPENDS, says it appears to be a typo.  I have no idea, it's for koobs to evaluate:

@@ -56,7 +56,7 @@ RUN_DEPENDS+=	7z:archivers/p7zip     \
 		${PYTHON_PKGNAMEPREFIX}kombu>=2.5.4:net/py-kombu               \
 		${PYTHON_PKGNAMEPREFIX}celery>=3.0.12:devel/py-celery          \
 		${PYTHON_PKGNAMEPREFIX}requests1>=1.1.0_9:www/py-requests1     \
-		${PKGNAMEPREFIX}pillow>=2.4.0:graphics/py-pillow               \
+		${PYTHON_PKGNAMEPREFIX}pillow>=2.4.0:graphics/py-pillow        \
 		${PYTHON_PKGNAMEPREFIX}pyparsing>=1.5.1:devel/py-pyparsing     \
 		${PYTHON_PKGNAMEPREFIX}ldap>=2.4.15:net/py-ldap                \
 		${PYTHON_PKGNAMEPREFIX}magic>0:devel/py-magic                  \
Comment 16 Kubilay Kocak freebsd_committer freebsd_triage 2016-08-05 12:28:12 UTC
(In reply to John Marino from comment #15)

Indeed a bug, should be PYTHON_PKGNAMEPREFIX, couldn't have passed testing
Comment 17 Dan Langille freebsd_committer 2016-08-05 18:26:22 UTC
(In reply to Kubilay Kocak from comment #16)

It passed testing last night when I was working on this PR.

http://services.unixathome.org/poudriere/data/102amd64-testing/2016-08-05_18h19m36s/logs/py27-crits-3.1.0_3.log

It passed again today with the patch.

http://services.unixathome.org/poudriere/data/102amd64-testing/2016-08-05_18h19m36s/logs/py27-crits-3.1.0_3.log
Comment 18 commit-hook freebsd_committer 2016-08-05 18:28:51 UTC
A commit references this bug:

Author: dvl
Date: Fri Aug  5 18:28:18 UTC 2016
New revision: 419698
URL: https://svnweb.freebsd.org/changeset/ports/419698

Log:
  - Fix ambiguous specification of libpcap by using libpcap from base
  - use PYTHON_PKGNAMEPREFIX instead of PKGNAMEPREFIX for pillow depends
  - Bump PORTREVISION

  PR:	211578

Changes:
  head/security/py-crits/Makefile
Comment 19 John Marino freebsd_committer 2016-08-05 18:36:40 UTC
Hey Dan, thanks.
I'm curious though, you wrote the same thing as garga, "Fix ambiguous specification of libpcap by using libpcap from base", but the code actually specifies libpcap from ports.

That's fine, it's just confusing because we can't tell if the commit message is inaccurate (you wanted from ports) or if the commit is wrong (you wanted it from base as the message states).

From my point of view, I don't care because the problem is solved in any case.  I just want to be sure it's fixed as you wanted it to be fixed.
Comment 20 Dan Langille freebsd_committer 2016-08-05 18:53:22 UTC
(In reply to John Marino from comment #19)
Yes, my commit message was inaccurate. I want to use libpcap from ports.
Comment 21 Renato Botelho freebsd_committer 2016-08-05 19:05:15 UTC
(In reply to John Marino from comment #13)

Fixed. Thanks!
Comment 22 commit-hook freebsd_committer 2016-08-06 00:10:38 UTC
A commit references this bug:

Author: marino
Date: Sat Aug  6 00:09:48 UTC 2016
New revision: 419718
URL: https://svnweb.freebsd.org/changeset/ports/419718

Log:
  net-mgmt/yaf: Fix dependency on libpcap

  The WITH_DAG knob implies that the ports version of libpcap is desired
  for yaf, not the base version as it is currently configured.  Fix the
  dependency specification accordingly.

  PR:	211578

Changes:
  head/net-mgmt/yaf/Makefile
Comment 23 commit-hook freebsd_committer 2016-08-06 00:41:43 UTC
A commit references this bug:

Author: marino
Date: Sat Aug  6 00:41:20 UTC 2016
New revision: 419721
URL: https://svnweb.freebsd.org/changeset/ports/419721

Log:
  net/xorp: Fix dependency on libpcap (use ports version)

  The specification on libpcap came on the v1.6 => v.1.8.5 transition
  while the port was unmaintained.  Assume the change originator intended
  for the ports libpcap to be used, but didn't realize it needed an
  explicit version number to avoid the base library from satisfying the
  requirement.  While here, remove an obsolete CONFLICTS definition.

  PR:	211578

Changes:
  head/net/xorp/Makefile
Comment 24 commit-hook freebsd_committer 2016-08-06 01:02:46 UTC
A commit references this bug:

Author: marino
Date: Sat Aug  6 01:02:28 UTC 2016
New revision: 419724
URL: https://svnweb.freebsd.org/changeset/ports/419724

Log:
  net/daq: Fix dependency on libpcap (use ports version)

  Back in r342092 (Jan 2014), the LIB_DEPENDS specification was updated
  from pcap to libpcap.so, which effectively moved the dependency from
  the ports version of libpcap to the base version.  The maintainer
  also indicated the ports listed in the PR should specify the net/libpcap.

  PR:	211578

Changes:
  head/net/daq/Makefile
Comment 25 John Marino freebsd_committer 2016-08-06 01:08:29 UTC
okay koobs,
security/suricata is the only one port left from the original list.
The fix is trivial.  I just checked the makefile and it's obvious that
PORTS_PCAL_LIB_DEPENDS needs to be changed to "libpcap.so.1:net/libpcap" based on the configuration arguments.  Can you go ahead and commit that so that I can close this PR?  Thanks.
Comment 26 commit-hook freebsd_committer 2016-08-06 03:48:59 UTC
A commit references this bug:

Author: marino
Date: Sat Aug  6 03:48:52 UTC 2016
New revision: 419730
URL: https://svnweb.freebsd.org/changeset/ports/419730

Log:
  security/py-crits: Really fix pillow depends

  The previous commit message indicated PYTHON_PKGNAMEPREFIX was added
  to the pillow dependency specification, but the commit didn't actually
  contain that change, so add it now.

  PR:	211578

Changes:
  head/security/py-crits/Makefile
Comment 27 commit-hook freebsd_committer 2016-08-06 08:52:19 UTC
A commit references this bug:

Author: koobs
Date: Sat Aug  6 08:51:43 UTC 2016
New revision: 419735
URL: https://svnweb.freebsd.org/changeset/ports/419735

Log:
  security/suricata: Fix libpcap LIB_DEPENDS

  Fix the PORTS_PCAP option LIB_DEPENDS entry ambiguously depending on
  net/libpcap, which should be libpcap.so.1 so as not to be satisfied
  with the pcap library provided by base. [1]

  While I'm here:

  - Explicitly BUILD_DEPEND on libhtp >= 0.5.20, as configure breaks when
    that minimum version is not available.

  PR:		211578
  Reported by:	marino [1]

Changes:
  head/security/suricata/Makefile
Comment 28 John Marino freebsd_committer 2016-08-06 13:15:32 UTC
Thanks Koobs!
Comment 29 Kubilay Kocak freebsd_committer freebsd_triage 2016-08-06 13:24:30 UTC
(In reply to John Marino from comment #28)
My pleasure John

I also had a thought. Might a USES=pcap[:ports] or something similar that provides all the correct (library/include paths, libname etc) variables for ports to use be a handy thing to have?
Comment 30 John Marino freebsd_committer 2016-08-06 13:31:03 UTC
A DF guy made the same suggestion, but I don't know if it's worth the effort.
Grepping would come up with the true number, but there might be 20 ports that use libpcap at most.  There are an untold (and undetectable) number of ports that use the base libpcap.  Given the second fact, I'd just say people need to be careful with libpcap (sysutils/file was the same issue).  

If you are asking my opinion, I'd say consider the issue closed.  The effort raised awareness on the issue.  FYI, Synth detected this issue.  It could be set up on FreeBSD to periodic do it (build the entire tree, then incrementally build it again.  If any ports fail sanity checks and rebuild, they probably have this issue or bad options definition).  Poudriere can't detect it.
Comment 31 John Marino freebsd_committer 2016-08-06 17:25:04 UTC
let me add a caveat.

If DF makes libpcap a private library, we would need to introduce USES=pcap:[port].  That could actually happen.  DF would be in a good position to catch the fallout as well.