On Tue, December 7, 2021 09:18, Rafael Sadowski wrote:
> On Thu Dec 02, 2021 at 05:03:13PM +0300, Kirill Bychkov wrote:
>> On Thu, December 2, 2021 16:06, Stuart Henderson wrote:
>> > On 2021/12/01 22:15, Antoine Jacoutot wrote:
>> >> At the time of import we did not want it to be picked up automatically by
>> >> random ports. Because we weren?t sure about the quality of it versus
>> other
>> >> local implementation of watchers in the applications themselves.
>> >> There were issues at the time, random locks, fd exhaustion etc.
>> >>
>> >> Things may be better now.
>> >
>> > Also even if it's working correctly, it results in software using a huge
>> > number of FDs, due to how file monitoring works with kqueue (I think this
>> > is not a problem with Linux's implementation). So sometimes a poll-based
>> > mechanism might be preferable.
>> >
>> >
>> Should we add a comment about this? This is not the first time that question
>> is asked.
>>
>
> I would very much welcome it.
>
Based on a Stuart's explanation:
Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/libinotify/Makefile,v
retrieving revision 1.16
diff -u -p -u -r1.16 Makefile
--- Makefile 24 Nov 2021 11:18:26 -0000 1.16
+++ Makefile 7 Dec 2021 11:26:58 -0000
@@ -22,6 +22,12 @@ DEBUG_PACKAGES = ${BUILD_PACKAGES}
SEPARATE_BUILD = Yes
CONFIGURE_STYLE = autoreconf
+
+# This is set intetntionally to non standard path to prevent software from
+# picking up libinotify automatically. The main reason is that with inotify
+# software is using a huge number of FDs, due to how file monitoring works
+# with kqueue. This allows to switch back to poll-based mechanism where it
+# is possible.
CONFIGURE_ARGS = --libdir=${PREFIX}/lib/inotify/ \
--includedir=${PREFIX}/include/inotify/
