wireshark doesn't build without libpng

[jkh@…]

--- Portfile	(revision 102878)
+++ Portfile	(working copy)
@@ -36,6 +36,7 @@
 		port:libgcrypt \
 		port:libgeoip \
 		path:lib/pkgconfig/glib-2.0.pc:glib2 \
+		port:libpng \
 		port:libsmi \
 		port:lua \
 		port:gnutls \

At least gets wireshark building again. Perhaps libpng should be the dependency of some other port in the dependency list.

[ryandesign (Ryan Carsten Schmidt)]

Remember to use WikiFormatting, to fill in the Port field and to Cc the maintainer of that port.

If wireshark is affected, I'll bet wireshark-devel is affected as well.

wireshark already depends on libpng indirectly (wireshark depends on gtk2 which depends on libpng). What exactly is the problem you see?

[cooljeanius (Eric Gallager)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Jordan, could you attach a log of the problem or tell me more about it?

[hsivank@…]

I try with differents gtk2, cairo and wireshark variants ... I cannot reproduce this bug on my system

[cooljeanius (Eric Gallager)]

According to my ​port-depcheck.sh script, there's a whole host of libraries (besides just libpng) that wireshark links against but doesn't declare a dependency on. I'll attach a diff next.

[cooljeanius (Eric Gallager)]

diff between libraries the wireshark port declares a dependency on and libraries that the wireshark port actually links against

[ghosthound]

Not going to add all of the dependencies of dependencies of dependencies... If someone thinks this is how all port should be done please reopen.

[larryv (Lawrence Velázquez)]

This is absolutely how it needs to be done. If wireshark can’t be forced to stop opportunistically linking to everything it runs into, we have to explicitly declare those dependencies. Otherwise users could easily break wireshark by accidentally removing those ports that wireshark capriciously linked to.

[ghosthound]

I disagree. For example, wireshark depends on glib2. In turn, glib2 depends on libxml2, which, in turn, depends on zlib. What I'm hearing is that we should include zlib as a direct dependency of wireshark because something wireshark depends on depends on something which depends on zlib. I think that's completely wrong, wireshark should not care what it's direct dependencies need. So far as users breaking a port by removing the dependencies of dependencies, they'd have to force the removal which is known to be a way to break things, whether the dependencies are direct or indirect.

I do agree that it is a problem if a port is linking in something which is not somewhere in the dependency chain, and that those should be fixed.

From a quick glance and the port-depcheck.sh and the dependency diff, it doesn't look like it takes into account the entire dependency chain.

[larryv (Lawrence Velázquez)]

Replying to ricci@…:

I disagree. For example, wireshark depends on glib2. In turn, glib2 depends on libxml2, which, in turn, depends on zlib. What I'm hearing is that we should include zlib as a direct dependency of wireshark because something wireshark depends on depends on something which depends on zlib. I think that's completely wrong, wireshark should not care what it's direct dependencies need.

Ideally yes, wireshark should not care about dependencies of dependencies. The issue is that its build system seems to make it start caring, even though we don’t want it to.

So far as users breaking a port by removing the dependencies of dependencies, they'd have to force the removal which is known to be a way to break things, whether the dependencies are direct or indirect.

Scenario:

1. wireshark opportunistically links to libxml2 but doesn’t declare a dependency on it.
2. glib2 stops depending on libxml2 (hypothetically). libxml2 might be a leaf now because wireshark did not declare a dependency on it.
3. User uninstalls leaves.
4. wireshark breaks.

I do agree that it is a problem if a port is linking in something which is not somewhere in the dependency chain, and that those should be fixed.

Right; this is what the others are asserting is happening. It’d be best if wireshark didn’t link to things willy-nilly.

(I personally have not looked into it.)

[ctreleaven (Craig Treleaven)]

The other issue is version upgrades of dependencies. Wireshark apparently directly links to libraries without listing those dependencies. How can a maintainer of a dependency know to rev-bump wireshark when they commit a major upgrade to a library? Answer: list the dependency.

[jmroot (Joshua Root)]

You have to depend on things that you use directly. If wireshark is caling libpng functions, it should depend on libpng. OTOH, it doesn’t need to depend on zlib just because libpng uses zlib; the dependency in the libpng portfile takes care of that. (Unless it is calling zlib functions itself and not just letting libpng call them, of course…)

[ghosthound]

First portion of resolving this in r128114 - added various ports that wireshark appears to be linking to (otool -L /opt/local/bin/wireshark, note that libpng is not in that output). This will need to be done for the gtk3 and qt variants as well. Other items installed by the wireshark port need to be checked for additional dependencies.