Bugzilla Bug 17772

from http://www.packetfactory.net/libnet/ :

Deprecated Tree (unsupported)

Latest Version: 1.0.2a

The SecurityFocus article on libnet 1.0.x written by Mike Schiffman.

All of the libnet code may be found here.

I still got it from the emerge libnet, shouldn't it be removed? (I know that
the latest version is available), or is it kept because of compability issues?

I believe compatibility issues are at play here, but I'll investigate. 
Actually, marty can you?

Its no longer possible to build version 1.0.2a of this package because the
source is not mirrored 
anywhere. 

Changing SRC_URI to the following makes it work again: 
 
SRC_URI="http://www.packetfactory.net/${PN}/dist/deprecated/${PN}-${PV}.tar.gz" 
 

I can tell you that most apps use libnet 1.0.x, and they changed the api
severely for 1.1.x.

I once tried porting something to using libnet 1.1, but it was more trouble
than it was worth, since it already worked :)

So don't go removing the ebuild!

Robert, there's libnet in net-libs and dev-perl -- do we need to rename the
dev-perl one?  If so, let me know, so it can be added to the list of package
moves, when stable portage is upgraded to know about moves.

Seemant, the libnet in net-libs and the libnet in dev-perl are two completely
different animals.  I have always considered "emerge package" as shorthand for
"emerge category/package" to be simply a convenience that could not necessarily
be relied upon in cases such as this, so I would just leave it.  If you want to
move it, however, it will probably need a new way of finding its SRC_URI.

ok, someone had already SLOT-ed libnet 1.0.x and 1.1.x so i touched up the SLOT
in 1.1.x and unmasked it ...

actually ill leave this open as a reminder ...

i want to switch the roles of libnet-1.0.x and libnet-1.1.x ...

that is, right now 1.0.x is sitting in /usr/lib/libnet.a, /usr/include/libnet/, and /usr/bin/libnet-config while 1.1.x has '1.1' suffixes on all of these ...

i'll be switching them such that 1.0.x has the suffixes and 1.1.x is in the standard locations ... fortunatly libnet is a static library and this change wont break any existing installs ;)

*** Bug 27022 has been marked as a duplicate of this bug. ***

ok, new libnet/libnids is now in portage ... ill leave this open for a little
while longer so as to help tracking of other packages ...

libnet-1.0.2a-r3:
SLOT=1.0
/usr/lib/libnet-1.0.a
/usr/include/libnet/libnet-1.0-<header name>.h
/usr/include/libnet-1.0.h
/usr/man/man3/libnet-1.0.3
/usr/bin/libnet-1.0-config

libnet-1.1.0-r3:
SLOT=1.1
/usr/lib/libnet.a
/usr/include/libnet/libnet-<header name>.h
/usr/include/libnet.h
/usr/share/man/man3/libnet.3
/usr/bin/libnet-config

libnet 1.0.2a-r2 and 1.1.0-r3 still overwrite each others header files!?

-r2 of both versions == stable
-r3 of both versions == unstable

either use both stable or both unstable otherwise it's your bug :p

hm, "nice":
libnet-1.1.0-r3 = x86
libnet-1.0.2a-r3  ~x86, but -r2 = x86

so stable/unstable is mixed for me 

thanks for clearifying this SpanKY - an einfo line wouldn't harm imho

thats interesting ... looks like someone marked it stable without telling
me ...

*looks at hillster*

pushing this SLOT-ed stuff to stable even though portage doesnt handle it
quite right :p

Please take a look at bug # 34632