On Mon, Jul 31, 2023 at 11:27:37AM +0200, Tobias Nygren wrote: > On Mon, 31 Jul 2023 08:38:31 +0000 > nia <n...@netbsd.org> wrote: > > > Hey, I regret that epoll was committed without further discussion with > > pkgsrc developers. We have a lot of experience with this already > > (illumos/SmartOS exposes a compatibility epoll) and the situation is > > not entirely great and requires lots of workarounds. > > > > Mostly, the situation of having epoll freely usable in public headers > > but discouraged in the man pages doesn't really work. Either we have > > barriers against its use, or we encourage its use. > > > > Software is mostly tested on Linux and FreeBSD, which have either epoll > > or kqueue. Build systems will detect epoll and use it. Autotools is > > falling out of favour, so it is getting harder and harder to override > > the detection of operating system functions. Build systems need to be > > patched. > > > > I don't want pkgsrc to be full of "don't use epoll on NetBSD" workaronds. > > > > I think the compatibility support should be opt-in. > > The problem is even if we hide this under a feature test macro, some > build systems only check for existence of the <sys/epoll.h> header, so > we will still end up patching some packages unless we rename the header > also. And the workarounds will be mostly the same as those for Illumos > so we can't get rid of them either. > > If the software supports kqueue(2) we obviously want to do that, > and I think we should tell the respective upstreams to default > to that on NetBSD so that we don't have to patch things. > > But what if the alternatives are select(2) or epoll(2)? > Is/will the implementation be mature enough to replace select(2) or > is this only ever intended for software that only supports epoll(2)? > > -Tobias
We can easily introduce a feature to pkgsrc that will cause the header to be automatically exposed for software that opts-in. We already do this for packages that expect ncurses. If FAKE_NCURSES is set, an artificial ncurses.h will be created in the build directory. If ALLOW_COMPAT_EPOLL is set, we could rename epoll_compat.h to epoll.h. NetBSD supports _much more_ Linux-centric software than illumos does.
