Bug 617326

What's the use when fprintd is auto-started when needed (eg. when applications actually use it, such as login programs, or user management apps)?

This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

The advantage is that we can start fprintd a little bit in advance: i.e. given that gdm uses it anyway it might make sense to start it already when we know we will go into graphical mode, so that it is already there when gdm asks for it. Of course, this alone will not give much of a speed-up, but if we do this across the board, then everything should already be there the first time somebody asks for it. In the current scheme we will start everything bus actviated exclusively on-demand which means that when somebody uses it he must wait until its startup is completed. This artificially slows down the boot and limtis parallelization.

Of course, this kind of early start-up only makes sense if we are pretty sure that the service will be required anyway, which I think is the case for fprintd.

But even ignoring this: it is a good idea to maintain bus activated services inside of systemd, simply because they then show up as normal daemons to the admin, he can inspect and control them with the usual tools and so on. We want services maintained at a single place, with a single UI instead of having a gazillion different ways how thigns are spawned and maintained.

BTW, if upstream is open for it I'd actually like to see this integrated upstream if possible.

(In reply to comment #4)
> BTW, if upstream is open for it I'd actually like to see this integrated
> upstream if possible.    

There's no upstream. Feel free to provide a patch to get it integrated anyway, and I'll commit it.

Johann, could you create a patch against upstream instead?

Git tree is at:
http://cgit.freedesktop.org/libfprint/fprintd/

Moving systemd service RFEs to rawhide.

At this point, it is not appropriate in the Fedora 15 cycle to add these. Furthermore, at this point, we are still finalizing the packaging guidelines to handle SysV -> systemd upgrades.

We therefore request:
- wait until there are packaging guidelines (this will be announced on the devel list). This ensures that upgrades will work smoothly and we/you won't have to do multiple sets of changes.
- work on these sorts of changes for Fedora 16 where necessary, not Fedora 15, as we're trying to fix things for release.
- do *not* change a service from SysV to systemd in an existing release (such as Fedora 15), as this is the sort of behavior change that goes against our update policy, documented as https://fedoraproject.org/wiki/Updates_Policy

Created attachment 524675 [details]
Adds systemd support, --with-systemd configure option

Bastien, this patch adds:

* --with-systemd flag to configure
* configure checks for systemd.pc, if found, sets HAVE_SYSTEMD
* data/Makefile.am has conditional on HAVE_SYSTEMD to install fprintd.service
* New file: data/fprintd.service

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

This bug can be closed:
% rpm -q fprintd
fprintd-0.5.0-1.fc19.x86_64
% rpm -ql fprintd|grep service
/usr/lib/systemd/system/fprintd.service
/usr/share/dbus-1/system-services/net.reactivated.Fprint.service