Service file:

http://pkgs.fedoraproject.org/cgit/dkms.git/tree/dkms.service

Have you actually tested the service file you have written there?

Would it be possible to add a smart ConditionPathExists= if any dkms module sources are actually installed? This should cut down initialization time for people who install the package without actually installing any modules.

Sorry for being late I was pretty busy.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #3)
> Would it be possible to add a smart ConditionPathExists= if any dkms module
> sources are actually installed? This should cut down initialization time for
> people who install the package without actually installing any modules.

Unfortunately there is not a single path to be checked; all modules put their sources in /usr/src and when installed they call dkms add <name>/<version> in %post. After this, the source is linked in /var/lib/dkms/<name>.

If there are no dkms packages installed (and so no /var/lib/dkms/<name> directory) the dkms command exits immediately; I don't see much difference here.

I would like also to point out that dkms is _never_ installed by default, so unless you install a dkms module package on your own (Fedora does not provide any) it will never be installed on any system.

Right now, before my update the service was still using SysV scripts that were unconditionally start at boot even in Fedora 20. Please see Fesco ticket about this.

Regards,
--Simone

(In reply to Simone Caronni from comment #4)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #3)
> > Would it be possible to add a smart ConditionPathExists= if any dkms module
> Unfortunately there is not a single path to be checked;
OK, that's fine, I was just checking if there's an easy way to optimize things a bit.

(In reply to Simone Caronni from comment #0)
> The dkms package has been unmantained for years; it still has a SysV init
> script up to current rawhide.

Did you actually do any research into why the package had been going on unmaintained before picking it up? 

From the looks of it has been superseded by KMP which got created with working group formed by the LF [1] 5 years ago and if that indeed turns out to be the case dkms should be removed from the distribution. ( KMP seems to be the reason why DKMS got rejected in OpenSuse [2] + this package is maybe something that belongs in rpmfusion...).

Michal/Kay/Harald know more about KMP

1. http://www.linuxfoundation.org/collaborate/workgroups/driver-backport
2. https://features.opensuse.org/305148

(In reply to Jóhann B. Guðmundsson from comment #6)
> 
> Michal/Kay/Harald know more about KMP

Might know more about KMP effort I mean...

Hello,

(In reply to Jóhann B. Guðmundsson from comment #6)
> (In reply to Simone Caronni from comment #0)
> > The dkms package has been unmantained for years; it still has a SysV init
> > script up to current rawhide.
> 
> Did you actually do any research into why the package had been going on
> unmaintained before picking it up?

it was not unmantained and revived, it was simply still included and left bitrotting. Since we are still using it at work for both RHEL and some Fedora installations I brought it up to date.

> From the looks of it has been superseded by KMP which got created with
> working group formed by the LF [1] 5 years ago and if that indeed turns out
> to be the case dkms should be removed from the distribution. ( KMP seems to
> be the reason why DKMS got rejected in OpenSuse [2] + this package is maybe
> something that belongs in rpmfusion...).
> 
> Michal/Kay/Harald know more about KMP
> 
> 1. http://www.linuxfoundation.org/collaborate/workgroups/driver-backport
> 2. https://features.opensuse.org/305148

Never heard of it. I doubt in the very short time we will migrate from DKMS but I will look into it, thanks.

Any news on adding to the preset file?

DKMS it's still widely used, I receive many requests / bugfixes and for Fedora 17/18/19 the service always started upon installation.

Changed in f20 fedora packaging git.

systemd-207-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/systemd-207-1.fc20

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

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

systemd-207-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.