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@…
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: | new → assigned |
comment:4 Changed 16 years ago by ghosthound
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
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 follow-up: 6 Changed 16 years ago by jmroot (Joshua Root)
Resolution: | invalid |
---|---|
Status: | closed → reopened |
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 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 follow-up: 9 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 follow-up: 10 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 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:12 Changed 15 years ago by tobypeterson
Resolution: | → duplicate |
---|---|
Status: | reopened → closed |
This is a base enhancement: #17473
This is related to #17154