It looks like a newer libnet/libnet-devel is now in EPEL.  I'll have to investigate what is going on with the package.  I imagine the static symbols were pulled out that syslog-ng needs to link against.

syslog-ng needs to statically link against libnet since the libraries are outside of /lib and might not be available if the system has an nfs-mounted /usr directory.  This is common for syslog packages.

Could you restore the static bindings to the -devel package or create a new -static package per the guidelines [1]?

If the static library was removed in other branches, could you restore it there as well?

[1] http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries

Static linkage is a special exception and should be decided on a case-by-case 
basis. The packager must provide rationale for linking statically, including 
precedences where available, to FESCO for approval. 

http://fedoraproject.org/wiki/Packaging:Guidelines#Staticly_Linking_Executables

For the moment, I don't see any reason, why syslog-ng should statically link to
libnet, we could move libnet library to /lib like we did for other libraries...

syslog packages have commonly statically linked libraries outside /lib, so I don't have a problem bringing this up to FESCO if necessary.  Moving libnet to /lib would be fine as well but I feel that it should only be done in rawhide to avoid a rebuild of all packages that link against it (I don't know - maybe there aren't many).

Let me know what your thoughts are.  syslog-ng has been statically linked against libnet since practically forever, but I don't really mind which solution we choose.  I might have to look at the configure script to see if it currently supports dynamically linking libnet, but that's a technical concern that can probably be handled fairly easily.  I'd like to get the policy stuff done as quickly as possible.

Wouldn't it also be a requirement that libnet be part of @Core (or something along those lines)?  Or is that only an issue for dynlibs linked against by the default syslog daemon?

Will have to read up on that.

In the past, libnet only shipped a static library. This changed with the new
upstream. Moving a shared library shouldn't cause a rebuild of all packages
that link against - it's a shared library on a standard library path, whether
its /lib or /usr/lib shouldn't matter for the depending programs. If syslog-ng
uses libnet-config(1) as nearly all other depending packages do, it works out
of the box usually.

@Core? Why? Dependencies are getting satisfied automagically?! And syslog-ng
has not a wide usage compared with syslog/rsyslog, sorry.

(In reply to comment #4)
>   Moving libnet to
> /lib would be fine as well but I feel that it should only be done in rawhide to
> avoid a rebuild of all packages that link against it (I don't know - maybe
> there aren't many).

I can't see why there would be a need to rebuild packages that link against libnet if libnet is moved to /lib. Wouldn't the linker find it in /lib as well as in %_prefix/lib/? In any case the -devel content (the .so and include files) should still be in %_prefix.

(In reply to comment #6)
> In the past, libnet only shipped a static library. This changed with the new
> upstream. Moving a shared library shouldn't cause a rebuild of all packages
> that link against - it's a shared library on a standard library path, whether
> its /lib or /usr/lib shouldn't matter for the depending programs. If syslog-ng
> uses libnet-config(1) as nearly all other depending packages do, it works out
> of the box usually.  

Sounds good; I wasn't sure that it would be handled properly if the library location moved.  If you're happy with moving libnet's library path I'll look into getting syslog-ng to link dynamically against it.

(In reply to comment #7)
> And syslog-ng has not a wide usage compared with syslog/rsyslog, sorry.  

While syslog-ng might not be the default syslog provider, it does have a wide user base and is very popular.

Fix for syslog-ng is in syslog-ng-2.1.4/configure.in, change:

  DEPS_LIBS="$LIBS $LD_START_STATIC $LEXLIB $GLIB_LIBS $EVTLOG_LIBS $LIBNET_LIBS $LIBWRAP_LIBS $LD_END_STATIC $LIBDBI_LIBS $DL_LIBS"

to

  DEPS_LIBS="$LIBS $LD_START_STATIC $LEXLIB $GLIB_LIBS $EVTLOG_LIBS $LIBWRAP_LIBS $LD_END_STATIC $LIBNET_LIBS $LIBDBI_LIBS $DL_LIBS"

for example. I don't know why there's static linking in EPEL anyway? I assume
you've checked, that static (mixed) linking on EPEL is really needed?

Let me know if this change works for you. If yes, I'll move libnet.so.* to the
/%{_lib} location as talked above.

Doug, see the following:

http://rayvd.fedorapeople.org/syslog-ng/syslog-ng.spec
http://rayvd.fedorapeople.org/syslog-ng/syslog-ng-2.1.4-4.src.rpm
http://rayvd.fedorapeople.org/syslog-ng/syslog-ng-2.1.4-libnet.patch

The patch is applied only on EL systems as syslog-ng seems to build fine under mock for Fedora.

I think you need to run autoconf after touching configure.in. Otherwise you
have to patch configure as well.

Yep, had to pull in autoconf as a BuildRequires.  It appears to be doing the right thing (didn't have to call it manually).

libnet-1.1.4-3.el4 has been submitted as an update for Fedora EPEL 4.
http://admin.fedoraproject.org/updates/libnet-1.1.4-3.el4

libnet-1.1.4-3.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/libnet-1.1.4-3.el5

libnet-1.1.4-3.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/libnet-1.1.4-3.fc10

libnet-1.1.4-3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/libnet-1.1.4-3.fc11

The libnet part is done, closing this bug report.

libnet-1.1.4-3.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

libnet-1.1.4-3.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

libnet-1.1.4-3.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

libnet-1.1.4-3.el4 has been pushed to the Fedora EPEL 4 stable repository.  If problems still persist, please make note of it in this bug report.