wireshark-1.0.4 needs rebuild after upgrading libpcap

[brad@…]

The wireshark package depends on the major version of libpcap, and as such requires rebuild when a new major version of that package is pushed.

ibuki:~ bsa3$ tshark -v
dyld: Library not loaded: /opt/local/lib/libpcap.0.dylib
  Referenced from: /opt/local/bin/tshark
  Reason: image not found
Trace/BPT trap

Suggested fix: push 1.0.4-1 with dependency on libpcap >= 1.0.0.

[brad@…]

This is related to #17154

[ghosthound]

Given that wireshark already depends on libpcap, how did you install the new libpcap without re-installing wireshark? In particular, if you did a force uninstall/install of libpcap without uninstalling wireshark, then there's no surprise that it broke. If this is not what happened, please re-open and report the exact steps taken the produce this problem.

[jmroot (Joshua Root)]

Wireshark was last updated 5 weeks ago, and libpcap was last updated one week ago. It's quite easy to imagine a user installing wireshark (and the old libpcap as a dep), and then running port upgrade outdated a while later, thus ending up with a new libpcap that the installed wireshark doesn't work with.

Bumping wireshark's revision should take care of this.

[ghosthound]

Replying to jmr@…:

Wireshark was last updated 5 weeks ago, and libpcap was last updated one week ago. It's quite easy to imagine a user installing wireshark (and the old libpcap as a dep), and then running port upgrade outdated a while later, thus ending up with a new libpcap that the installed wireshark doesn't work with.

Bumping wireshark's revision should take care of this.

"port upgrade" should rebuild dependencies, and in the guide this appears to be the case (though it isn't entirely clear):

"The upgrade option upgrades installed ports and their dependencies when a Portfile in the repository has been updated after a port was installed."

If someone uses "port upgrade outdated" and the bumped libpcap doesn't result in dependencies (like wireshark) being rebuilt, I think that's a bug with "port upgrade" and should not be fixed by band-aiding ports every time their dependencies are changed.

If the filer of the ticket could include the commands (and other details) that were used to get their install into this state, that would be helpful.

[jmroot (Joshua Root)]

Upgrade will never rebuild anything that is already the latest version unless you use -f. Also, wireshark isn't a dependency of libpcap, it's a dependent, so it won't be considered for upgrade when you ask to upgrade libpcap unless you use -R.

I agree that there ought to be a way to specify that an update requires all dependents to be rebuilt.

[ghosthound]

I also don't feel that the right solution is to give wireshark a revision bump to handle a dependency upgrade. Is there a reason we don't make make 'port upgrade -R' the default?

[blb@…]

Replying to ricci@…:

I also don't feel that the right solution is to give wireshark a revision bump to handle a dependency upgrade. Is there a reason we don't make make 'port upgrade -R' the default?

A minor update to base-level ports (eg, zlib, libpng, etc) would then trigger a rebuild of many, many ports.

[ghosthound]

Replying to blb@…:

Replying to ricci@…:

I also don't feel that the right solution is to give wireshark a revision bump to handle a dependency upgrade. Is there a reason we don't make make 'port upgrade -R' the default?

A minor update to base-level ports (eg, zlib, libpng, etc) would then trigger a rebuild of many, many ports.

Yes, it would. When that's the "right" thing to do (and when it is not) is not obvious from what knowledge we can (currently) provide in a Portfile, nor is it across-the-board easy to tell when a minor rev of a library will have API changes (it does happen, most unfortunately). It would make a great project for somebody to work on (next summer?) - to have port grok when it should do dependent rebuilds and when it should not.

Given the pain of rebuilding so many things, having 'port upgrade -R' be the default is probably not the right answer.

Having some sort of key in the Portfile that indicates that the port author believes the change does require dependent rebuilds would (appear to) solve the problem.

[(none)]

Milestone Port Bugs deleted

[tobypeterson]

This is a base enhancement: #17473