Wireshark mailing list archives
Re: wireshark-devel package - Was: [Wireshark-core] Working up to a new stable branch (1.6)
From: Balint Reczey <balint.reczey () ericsson com>
Date: Tue, 31 May 2011 15:18:07 +0200
Hi Joerg, On 05/31/2011 12:02 AM, Joerg Mayer wrote:
[Moved this to wireshark-dev as it still does not belong onto wireshark-core] On Mon, May 30, 2011 at 04:18:31PM +0200, Balint Reczey wrote:I still don't know how it works when we don't install header files, network except have copy of wireshark .h files?On Debian we ship .h files in the wireshark-dev (libwireshark-dev, libwiretap-dev, libwsutil-dev in recent package versions). netexpect build-depends on those packages.OK, as this seems to repeat every 6-8 months right now, let me repeat my standard answer to this as well: The library was never meant to be used outside Wireshark (well, Ethereal). It was created to prevent us from linking the same code into ethereal and tethereal. We do not have a proper API and looking at the hoops people are jumping through to create a "devel" package is just plain ugly: iff some people really feel they want to create a devel package that is not endorsed by the majority of wireshark developers then at least do it properly: create proper include files instead of just adding more and more includes files of the normal dissctors etc. Most likely this will need to be redone for each major release, but that's what you get when you effectively create a fork (although for packaging purposes only).
You almost correctly summarized what I would like to see changed. The library was never meant to be used outside Wireshark, but other projects, like Network Expect [1] would like to use it.In my opinion the Open Source world is about sharing. How could we capture packets with Wireshark if the Tcpdump project did not provide the libpcap as a shared library?
I think now it is our turn to make our libraries usable for other OSS projects.Eloy Paris, the developer of netexpect helped a lot in separating the libraries to new Debian packages and I also did some work to not exporting symbols on UN*X systems not exported on Windows. Now it is also possible to easily dump ABI information and we could use it for setting the correct library versions while preparing releases.
In my opinion everything is ready, and we could start versioning with little effort.You are right that we should reorganize .h files, too. I proposed this step for 1.8.0 in my one of previous emails. Currently we (the Wireshark project) provide
the .h files in the wireshark-dev package, see debian/control.For 1.6.0 we could start by bumping the library versions to 1.0.0 and refraining from making big changes affecting the major library version in 1.6.x releases.
Since there is no officially stable representation of the undissected traces this wouldn't be a stable solution either.The only "stable" solution that I see is to create something like ipcshark where the dissection is running as a service and other processes just use this service by feeding it undissected traces plus some specification on the dissectoin details and the output format and receive the disscted stuff back in said format. Of course you loose a bit of performance, but that is the only stable longtime solution i see.
Cheers, Balint PS: [1] http://netexpect.org
Ciao Jörg -- Joerg Mayer<jmayer () loplof de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- wireshark-devel package - Was: [Wireshark-core] Working up to a new stable branch (1.6) Joerg Mayer (May 30)
- Re: wireshark-devel package - Was: [Wireshark-core] Working up to a new stable branch (1.6) Balint Reczey (May 31)