Bug#885011: libgio-fam: Remove this package?

[Simon McVittie]

[Ccing the non-Linux-kernel lists since this is to do with a package
that only their ports get]

On Fri, 22 Dec 2017 at 16:02:23 -0500, Jeremy Bicha wrote:
> As part of Debian GNOME's svn to git conversion, it makes sense to
> evaluate whether we still need deprecated and unmaintained packages in
> Debian. One of those is gamin. [1]
> 
> I see that libgio-fam is only built on hurd and kfreebsd. See
> https://bugs.debian.org/526219 for some background on that. (Neither
> fam nor gamin have been in Ubuntu "main" since at least 12.04. It
> appears like fam/gamin was more of a gnome-vfs thing so not needed
> since GNOME 3).

I think you're misreading #526219, but your conclusion might be valid
anyway.

The goal is that GFileMonitor detects file changes without polling. On
Linux, it does that without external code, because GLib has a
built-in GFileMonitor backend that uses inotify. On kFreeBSD at the
time of #526219, there was no built-in kqueue backend for GFileMonitor
(kqueue is a FreeBSD API that provides the equivalent of Linux inotify,
among other things), so FreeBSD users had to either use an external
library that does know how to use kqueue (fam/gamin), or resort to
periodic polling. However, modern GLib contains something called
gio/kqueue/gkqueuefilemonitor.c (and according to build logs, we
even build it), which suggests that a kqueue GFileMonitor might now
be provided. Hopefully the kFreeBSD porters can advise whether that
backend actually works, and if not, send patches upstream to fix it.

The reference to gnome-vfs in #526219 was to say that unlike GFileMonitor,
the equivalent of GFileMonitor in gnome-vfs didn't know how to use
inotify on Linux, which is why fam/gamin used to be desirable on Linux.
That is thankfully now a thing of the past, and we only keep libgio-fam
for the non-Linux kernels' benefit.

I don't know whether Hurd supports a file-change-monitoring API better
than periodic polling; according to GLib and gamin build logs, it
doesn't seem to have a Linux-compatible inotify or a FreeBSD-compatible
kqueue, and I don't see any successful configure checks for anything that
looks analogous.

I think the options for the GNOME team are:

1. Stop building libgio-fam, and orphan gamin if it has no more GNOME rdeps
   (it does unfortunately have rdeps outside GNOME, notably lighttpd and
   libkf5coreaddons5). Hurd no longer gets to multiplex its inefficient
   polling through the gamin daemon (assuming I'm right in thinking that
   Hurd has no API for this that our libraries support), so GFileMonitor
   might become even less efficient on Hurd than it currently is (all
   processes that monitor files wake up periodically, not just the gamin
   daemon), but that doesn't seem a huge loss.

2. Keep building libgio-fam, but only on Hurd, and orphan gamin if it
   has no more GNOME rdeps; warn Hurd porters that if it becomes a
   maintenance problem, then libgio-fam will be removed altogether
   (switching to option 1).

3. Keep libgio-fam on both kFreeBSD and Hurd, and maybe orphan gamin,
   warning both sets of porters that if it becomes a maintenance problem.
   then libgio-fam will be removed (switching to option 1). This should
   only be done if kFreeBSD porters tell us that gamin is significantly
   better than gkqueuefilemonitor.c (but if that's the case, fixing
   gkqueuefilemonitor.c would be a better solution for the kFreeBSD people
   than keeping gamin, IMO).

Regards,
    smcv