Red Hat Bugzilla – Bug 151141
Split off ethereal-devel from ethereal
Last modified: 2007-11-30 17:11:01 EST
Description of problem:
Currently, in order to develop new ethereal plugins on Red Hat or Fedora one has
to download the ethereal source (tarball or SRPM) and develop them within that
tree. This is because the header files from ethereal are not available in any RPM.
This bug is a request to have a new package, ethereal-devel, built that contains
these ethereal header files. This package can also take ownership of the
"idl2eth" tool currently in the ethereal package, since this tool is only used
to build ethereal plugins (and is therefore totally useless in the existing
I have attached a patch to the ethereal spec file that builds an ethereal-devel
package. The patch is against ethereal-0.10.9-1.FC3.1, though it patches fairly
cleanly against the latest in Fedora's devel tree (ethereal-0.10.10-1).
In determining the header files to include I took inspiration from the way
Debian builds its ethereal-dev package. The list of headers is in
ethereal.header-files (also attached) -- this'll be an extra source file in the
The spec file patch also includes the necessary changes to move idl2eth (plus
its manpage) to the -devel package. Technically the various documentation files
should be sorted out (some are user docs, some are developer docs), but at the
moment they're all left in the ethereal package.
Finally, the spec file patch includes a change to the "evil plugins hack" to
make it easier for package builders to use "rpmbuild -bi --short-circuit" --
without this change subsequent rpmbuilds muck up the paths in the .la files.
Created attachment 112012 [details]
Spec file patch to build ethereal-devel
Created attachment 112013 [details]
Header files to place in ethereal-devel
I'm planning to create a ethereal-devel package already for some time. There's
just one small problem, which is caused by ethereal developers. Every new
release removes several library symbols and adds plenty of new. At the moment, I
can't ensure that the plugins created with one version of devel package will
work in the upcomming version. Also the way plugins work was changed several times.
Nice example is the latest ethereal-0.10.10 compared with previous 0.10.9
version. I did a small lib diff using dd and I can see that in almost all
plugins the symbol "plugin_init" disappeared and some symbols are missing in the
libethereal.so - alltogether, there are 36 missing symbols in new libethereal.
Can't say how crucial it is but I think you got my point.
New ethereal versions come out once in two months, fixing several security
issues. It would be a big pain backporting all the "on the way" lost symbols and
keeping support for a devel package. If the libethereal will freeze on certain
degree of stability, I'm sure we'll push out the devel package.
I understand your concern -- as soon as there's an official ethereal-devel
package there's the expectation that Red Hat will make sure it always "Just Works".
However, I think in general if someone was developing their own ethereal
plugins, they would be aware that they wouldn't always be forward-compatible.
I'm already having to make changes to my own plugins so they work with 0.10.10,
and this would be the case whether I was using an official ethereal-devel or not.
Here's a snip from discussion about ethereal-devel package on developers mailing
libethereal in it's current state isn't meant to be used by other
programs than the Ethereal package itself, as this would require a lot
The main purpose was to simply save code space as both ethereal and
tethereal uses a whole lot of identical code (that's how I
Someone else might correct me, but there are currently no attempts to
bring libethereal into a state where other programs (like your's) can
conveniently use libethereal. This would require more work, like making
it possible to keep multi instances of everything and ...
I do agree that this goal would be useful. But believe me, the Ethereal
developers have still a lot of other work to do ;-)
The discussion continues here
And it also seems than many developers wants to change the current API. So
spliting of the devel package will propably not happen in near future.