Comment 1 for bug 1853830

Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote : Re: [MIR] gamemode

Good packaging practice: despite the missing trailing comma, dh has fail-missing, la files are not shipped, upstream is called with --as-needed. Hardening flags are enabled.

1/ One lintian warning that I’m fine to ignore (but will be better to fix it in lintian or have an override): W: gamemode source: incorrect-packaging-filename debian/TODO.debian -> debian/TODO

inih has been devendorized. OK

2/ I know that the soname is still at 0. However, I would like to have symbols files present with makeshlibs called -c4 for both libs please. I find it concerning now that release 1.X is reached, we still have an unstable ABI and it should be tracked. I saw there is an explicit lintian override for skipping them. Is there any reasons which is still valid and we don’t want to track the API?

3/ There are now 2 (very recent, I admit :p) bugs in launchpad. I think bug #1862455 should be investigated while the package should be updated to 1.5 instead of a git snapshot (bug #1863570).

4/ The daemon is executed as root from a user process which talks to the daemon via dbus and authenticate via polkit. Note that the dbus activated service or the user activated service have different options:
- The -d option is fine as the dbus activated is called with a daemonizing options but not the systemd one (prefered way of working if activated by systemd)
- However, I don’t understand why the systemd service is called with -l (log to syslog), which is out default for systemd service (the journal forwards to syslog, even for user services). The day we want to remove syslog completely, it will prevent having to patch it.

5/ I am not completely sure why the 2 -dev are separated. However, as the only libgamemodeauto-dev ships some headers, are you sure that we can build against libgamemodeauto0 without having those headers installed? If not, libgamemodeauto-dev should dep on libgamemode-dev.

6/ I think libmode* should recommends, provides some alternative or at least suggests the package having the daemon.

When those are fixed (in particular the update to 1.5), I would like to request a security review as this daemon is root executed by an user command.