Discussed at today's FESCo meeting with several questions:

• Why presets? We don't think that presets are the correct technology for packages to be using. Presets are for the distribution and spins to use to configure a service to be on or off independently of the packaging. The standard seems to be more about getting permission from fesco to start your service automatically. Once permission is granted, the default preset in the systemd package is modified to make that happen on a default Fedora install.
• What does your package need to do? What are you requesting here? i'm sorry but we had a lot of trouble figuring out what you were intending to say. Perhaps showing us the diffs/spec/code that you are changing or is relevant would help. Code seems to be a common language for all of us :-)

1-why) configuration continuity, code reuse, all in one place (modules+service reconfiguration)

1-systemd package) that will be always on. not conditional on for ipmi capable hardware only.

2-need to) module probing in ipmi.service

2-request) on by default AND conditional preset management

2-code) just rough schema.
{{{
diff --git a/OpenIPMI.spec b/OpenIPMI.spec
index 6174499..d09ebc8 100644
--- a/OpenIPMI.spec
+++ b/OpenIPMI.spec
@@ -96,6 +96,11 @@ install -m 644 %SOURCE3 ${RPM_BUILD_ROOT}%{_unitdir}/ipmi.service
rm ${RPM_BUILD_ROOT}/%{_mandir}/man1/openipmigui.1

%post
+if [ $1 -eq 0 ] ; then
+ if [ -d /sys/....../IPI0* ] ; then
+ %{__ln_s} /_some_private_path/ipmi-on.preset /usr/lib/systemd/system-preset/XY-ipmi-on.preset
+ fi
+fi
%systemd_post ipmi.service

%preun
}}}

I'm still not sure why a package-private preset would be the best solution.

• spins (and for that matter, site administrators) should be able to override the enable/disable state using preset files. So the package-private preset should have lower priority than the spin and sysadmin presets.
• If the package-private preset has lower priority than the spin and sysadmin presets, we might just as well add it to the default preset.

The only advantage I can see is that the [ -d ... ] check happens only at installation time instead of at boot time, which is a very small advantage - and probably outweighed by extra work required when the disk is moved from a computer that doesn't have IPMI to a computer that does have it.

I'd suggest filing a bug against systemd to add the service to the default preset file, and to implement a way to make the functionality conditional that doesn't depend on changing presets (e.g. add the [ -d /sys/.../IPI0 ] check to the service itself, or use a Condition= in the service file.)

In today's FESCo meeting, we agreed with the suggestions mitr made above. Namely, FESCo does not believe a package-private solution to this is the correct method. We suggest you file a bug against systemd to get it added to the default preset file and rework the service to do detection of hardware to do the addional module loading and watchdog starting at boot time