Hi developers, I am a non-DD member of the Debian Perl Group. In the process of packaging the libev-perl package, an event loop for Perl, I stumbled upon the fact that it does not link against libev as a shared object, but instead builds it into its own binary. libev has a "feature" that allows you to build it differently - changing some structs to add customized fields - via a #define. Essentially, every included libev is different than the other ones, therefore you can't simply get rid of this by switching to dynamic linking. I e-mailed upstream about this, but he basically considers this a feature and, remembering of the OpenSSL fiasco, warned not to fiddle in upstream code. As per Policy 3.8.0, packages should not include copies of other packages. I think the best way would be to fix the library and provide another way to include additional fields into its data structures, using the classic approach of a pointer to userdata. However, that would require us to patch any application using libev this way. The second option I came up with was creating a libev-source package from the existing libev package and build packages including libev against this one. Bugs in libev would then only require a rebuild of the dependent packages instead of source package fixing. I think this solution is suboptimal but less invasive. AFAIK the only affected package currently in Debian is rxvt-unicode (see #512487). From the README of libev: Examples of programs that embed libev: the EV perl module, rxvt-unicode, gvpe (GNU Virtual Private Ethernet), the Deliantra MMORPG server (http://www.deliantra.net/), Rubinius (a next-generation Ruby VM), the Ebb web server, the Rev event toolkit. I have not checked whether the mentioned software includes libev or builds against the dynamic library properly. Regards, Maximilian Gaß
Attachment:
signature.asc
Description: Digital signature