Opened 16 years ago

Closed 15 years ago

#17361 closed defect (duplicate)

wireshark-1.0.4 needs rebuild after upgrading libpcap

Reported by: brad@… Owned by: ghosthound
Priority: Normal Milestone:
Component: ports Version: 1.6.0
Keywords: Cc:
Port: wireshark

Description

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.

Change History (12)

comment:1 Changed 16 years ago by brad@…

This is related to #17154

comment:2 Changed 16 years ago by mr_bond@…

Owner: changed from macports-tickets@… to opendarwin.org@…

comment:3 Changed 16 years ago by ghosthound

Owner: changed from opendarwin.org@… to ricci@…
Status: newassigned

comment:4 Changed 16 years ago by ghosthound

Resolution: invalid
Status: assignedclosed

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.

comment:5 Changed 16 years ago by jmroot (Joshua Root)

Resolution: invalid
Status: closedreopened

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.

comment:6 in reply to:  5 Changed 16 years ago by 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.

comment:7 Changed 16 years ago by 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.

comment:8 Changed 16 years ago by 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?

comment:9 in reply to:  8 ; Changed 16 years ago by 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.

comment:10 in reply to:  9 Changed 16 years ago by 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.

comment:11 Changed 16 years ago by (none)

Milestone: Port Bugs

Milestone Port Bugs deleted

comment:12 Changed 15 years ago by tobypeterson

Resolution: duplicate
Status: reopenedclosed

This is a base enhancement: #17473

Note: See TracTickets for help on using tickets.