Bug 151141 - Split off ethereal-devel from ethereal
Split off ethereal-devel from ethereal
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: ethereal (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-15 06:52 EST by Michael Chapman
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-30 04:08:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Spec file patch to build ethereal-devel (2.41 KB, patch)
2005-03-15 06:52 EST, Michael Chapman
no flags Details | Diff
Header files to place in ethereal-devel (755 bytes, text/plain)
2005-03-15 06:53 EST, Michael Chapman
no flags Details

  None (edit)
Description Michael Chapman 2005-03-15 06:52:19 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
package).

Proposed fix:

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
SRPM.

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.
Comment 1 Michael Chapman 2005-03-15 06:52:19 EST
Created attachment 112012 [details]
Spec file patch to build ethereal-devel
Comment 2 Michael Chapman 2005-03-15 06:53:48 EST
Created attachment 112013 [details]
Header files to place in ethereal-devel
Comment 3 Radek Vokal 2005-03-15 07:21:23 EST
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. 
Comment 4 Michael Chapman 2005-03-16 03:04:03 EST
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.
Comment 5 Radek Vokal 2005-05-30 04:08:53 EDT
Here's a snip from discussion about ethereal-devel package on developers mailing
list...

>> 
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
more effort.

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
understand/remember  it).

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 ;-)

Regards, ULFL
>>

The discussion continues here
http://www.ethereal.com/lists/ethereal-dev/200505/msg00468.html

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. 

Note You need to log in before you can comment on or make changes to this bug.