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
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.
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.
(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.
(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.
Package Change Request
Package Name: libnet
Updated Fedora CC: email@example.com
Adding per the new static linking guidelines, and I maintain ettercap and
etherbat that link against libnet. No review bug found, using this one.
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.
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.
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.
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
The only drawback is that all the package maintainers that
depend on libnet should be in initial CC, however libnet bugs
are very rare.