Remove libev inclusion

[GoogleCodeExporter]

pyev currently provides its own version of libev.

This is a bad choice in term of security and maintainability. As the futur
Debian maintainer of this package, I would remove the libev which is
included in the source tree to use the Debian provided one.

Attached is 2 patches to remove dependency on libev. I did not test them
but you will get the idea.

Original issue reported on code.google.com by jdan...@gmail.com on 30 Dec 2009 at 9:24

Attachments:

• 0001-do-not-use-libev-version.patch
• 0002-remove-dependency-on-ev.c.patch

[GoogleCodeExporter]

Hi,

I'm not against these at first glance, but I think you should know why I did 
embed
libev, before you go on with it.

I refer you to: http://lists.schmorp.de/pipermail/libev/2008q1/000232.html and
http://lists.schmorp.de/pipermail/libev/2008q2/000381.html (and follow ups).

To sum it up, Python being, in general, built with support for large file, it 
creates
a problem with Stat watchers, rendering them unusable. Upstream is not leaning 
toward
adding support for LFS (relying on system defaults), and a lot of distros 
(including
Debian, I think) leave this matter alone (for devs to decide what's best).

That leave us with few options:

- add LFS support in Debian's libev package (maybe it's already there?)
- get rid of Stat watchers in pyev (I'm not fond of this one)
- keep libev embedded 
- ???

If you have a better idea on how to solve this (I never spent enough research 
time on
this), I'd be then happy to rely on an external libev for pyev.

As usual, if I'm wrong or if I overlooked something, feel free to correct me 
:-).

malek

Original comment by lekma...@gmail.com on 4 Jan 2010 at 11:55

[GoogleCodeExporter]

Sorry for the delay, but obviously I didn't get any mail from this bug tracker 
of
your answer. :-(

I don't think libev in debian as been compiled with LFS support, because AFAIK 
it is
not patched in this way. However, this is fixable.

Most distributions nowadays have enabled LFS support everywhere, so it's 
assumable
that your patch (AC_SYS_LARGEFILE) with some pkg-config flag would have been a 
nice
enough solution.

Unfortunately upstream seems to feel differently. :-(

I'll try to see if I can come up with a better solution.

Original comment by jdan...@gmail.com on 11 Jan 2010 at 3:34

[GoogleCodeExporter]

Original comment by lekma...@gmail.com on 20 Jul 2010 at 9:03

• Added labels: Type-Enhancement, Priority-Low
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

Hi, I'm trying to package pyev for downstream distro (gentoo linux), and also 
face the same problem. bundle library is pretty bad for the maintainer, I'm 
suggest at least you make it optional, so we can disable it at build time. 

thanks

Original comment by dennis.y...@gmail.com on 6 Mar 2013 at 7:01

[GoogleCodeExporter]

all right guys, next release will remove libev (and get rid of Stat watchers).

Original comment by lekma...@gmail.com on 11 Mar 2013 at 6:32

[GoogleCodeExporter]

thanks, I'm waiting for you to release next version. 
and one minor problem here, could you remove the suffix version of libev when 
release pyev? example, I think it's better to have 0.8.1 rather than 
0.8.1-4.04, since 4.04 here is the libev version number. you can of course 
check the libev version if you like.

http://www.gnu.org/software/autoconf-archive/ax_lib_ev.html#ax_lib_ev

Original comment by dennis.y...@gmail.com on 12 Mar 2013 at 5:38

[GoogleCodeExporter]

You might consider making the libev inclusion optional, if it is convenient in 
some cases.

I actually am thinking of doing the same thing with pymssql, which in some 
cases bundles a version of a library called FreeTDS.

My current thought is to make it optional by borrowing from the setup.py in the 
pyzmq project -- it looks to me like they have a pretty comprehensive system 
for controlling whether or not to bundle libzmq.

Something to consider.

Original comment by msabr...@gmail.com on 24 Mar 2014 at 3:27