Bug 243575 - Patches exist to build libnet dynamically.
Patches exist to build libnet dynamically.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: libnet (Show other bugs)
rawhide
All Linux
medium Severity low
: ---
: ---
Assigned To: Patrice Dumas
Fedora Extras Quality Assurance
http://ftp.debian.org/debian/pool/mai...
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-09 20:06 EDT by Jason Tibbitts
Modified: 2008-01-27 15:43 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-27 15:43:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
wtogami: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Jason Tibbitts 2007-06-09 20:06:02 EDT
Debian ships a dynamic libnet library, presumably using some patches they have.

Unfortunately as things are now, packages (in Fedora) using libnet must
statically link against it, which requires FESCo approval.  And I'm concerned
that they won't approve, because libnet could theoretically be shipped as a
dynamic library.  I'm sure they'll at least want to know why we ship a static
library while Debian doesn't.

In that unfortunate debian style, their patches are mashed together in
http://ftp.debian.org/debian/pool/main/libn/libnet/libnet_1.1.2.1-2.diff.gz

Dost of that file seems to be aclocal.m4, ltmain.sh and configure.  I guess
they're including the result of autoconf in the patch.
Comment 1 Patrice Dumas 2007-06-10 05:56:34 EDT
I know about that patch very well, but upstream is
dead, but I think that someday the project will restart. There was
something on alioth (the patch certainly comes from there), but it 
is dead, too. In the mean time I don't want to use an ABI 
versioning scheme not agreed by upstream.

I also asked for debian to split their patch, but they never responded
(in some case their patch are nicely split).

Agreed, it was less an issue before when there wasn't a lot 
of packages building against libnet, now I may reconsider my
decision, but I still find uncomfortable about adding a shared lib
on a project I think upstream will exist once again in the future.
Comment 2 Toshio Kuratomi 2007-06-11 02:04:09 EDT
(In reply to comment #1)
> I know about that patch very well, but upstream is
> dead, but I think that someday the project will restart. 

Could you clarify what indications you have that upstream will restart and when
that might happen?

Our policy is that if upstream is dead the packager has to take on many of the
responsibilities of upstream.  Viewed in that light, supporting dynamic linkage
of a networking library is a security enhancement that seems good to make. 
Since Debian already has a patch that adds that feature, collaborating with them
on the ABI versioning will aid the users of both our distros.
Comment 3 Patrice Dumas 2007-06-11 12:39:37 EDT
(In reply to comment #2)
> (In reply to comment #1)
> > I know about that patch very well, but upstream is
> > dead, but I think that someday the project will restart. 
> 
> Could you clarify what indications you have that upstream will restart and when
> that might happen?

I have no indications, but it is the only package (unless I am 
missing something) that provides that functionality, and it is
used in many projects. So I think that some day somebody wanting
a new functionality will take over libnet.

> Our policy is that if upstream is dead the packager has to take on many of the
> responsibilities of upstream.  Viewed in that light, supporting dynamic linkage
> of a networking library is a security enhancement that seems good to make. 
> Since Debian already has a patch that adds that feature, collaborating with them
> on the ABI versioning will aid the users of both our distros.

Aid or harm. I will try to contact debian folks once again and 
decide from here.
Comment 4 Gwyn Ciesla 2007-07-03 11:23:18 EDT
Package Change Request
======================
Package Name: libnet
Updated Fedora CC: limb@jcomserv.net

Adding per the new static linking guidelines, and I maintain ettercap and
etherbat that link against libnet.  No review bug found, using this one.
Comment 5 Robert Scheck 2007-11-27 07:49:38 EST
Does this debian patch add *.so files? If yes, please re-open this bug report
immediately, because static linking is IMHO just crap. Please apply this patch
as soon as possible if there are *.so files coming up.

As far as I know, the package had no review and if there won't be any *.so with
the next rebuild of libnet, I'll notice FESco about this, because cases like here
require a FESco approval.
Comment 6 Patrice Dumas 2007-11-27 16:33:30 EST
You misread the guidelines, the FESco approval is for statically
linked executables. The provision for libraries shipping only
static are there.

Now, about adding shared libraries while they are not upstream,
it is problematic in case future upstream sonames are the same than
past sonames used in distro.

Indeed static linking, in the case of libnet is unfortunate. If you
really want to have dynamic linking, maybe you could try to 
become upstream? A project was launched in alioth but it looks dead.
There is a beta version, 1.1.3, since 2005. Contacting debian and
other distros may also be a good idea.

Review is Bug 165963.
Comment 7 Robert Scheck 2007-11-27 16:47:37 EST
Well, you are the maintainer of this package, so it would be more your turn than
mine. Anyway, I've a package in review which depends on yours and static linking
is not the right thing here. And why do you care to add the patch anyway, if the
project is almost dead? Then it shouldn't hurt anyway somebody.
Comment 8 Patrice Dumas 2007-11-28 04:11:22 EST
I am not a seer, but I think that the project will be revived
some day. In fedora there are 9 package depending on libnet, and I
don't see another library providing what libnet provides. So  I
hope that a packager or an upstream maintainer will, one  day,
step up and revive libnet. If the future sonames chosen by the
new upstream collide with the fedora soname it will be very 
painful.

The only drawback is that all the package maintainers that 
depend on libnet should be in initial CC, however libnet bugs
are very rare.

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