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