Bug#810367: kmod-static-nodes.service fails without a dependency on kmod

[Helmut Grohne]

Control: severity -1 wishlist

Hi Felipe,

On Fri, Jan 08, 2016 at 01:11:29PM -0300, Felipe Sateler wrote:
> kmod-static-nodes.service already has:
> 
> ConditionPathExists=/lib/modules/%v/modules.devname
> 
> That is, you have a kernel installed that require static device node
> creation. On my system I do:
> 
> % aptitude why kmod
> i   linux-image-amd64          Depends linux-image-3.16.0-4-amd64
> i A linux-image-3.16.0-4-amd64 Depends kmod | module-init-tools
> 
> (m-i-t is a transitional package for kmod).
> 
> So, evidently you have a self-built kernel. Is it reasonable to expect
> self-compiled kernel users to satisfy the dependencies of the kernel
> packages? I'm not sure there is a clear-cut answer for this. But if
> you are compiling a kernel with module support, not installing kmod
> looks very weird to me.

Hmm. Looks like I didn't look far enough. So this certainly isn't an
issue for any packaged kernels and it also isn't an issue for any
module-less kernels.

> Or have your kernel not ship the modules.devname if it is empty. (BTW,
> is it actually empty, or does it contain a comment? If it is empty,
> then maybe we can change to ConditionFileNotEmpty).

depmod always[1] adds that comment. Having both depmod skip the comment
and ConditionFileNotEmpty sounds like a superior solution to me. Not
sure whether the kmod maintainers like that idea though.

So I see two ways forward:
a) Clone to kmod asking to remove the comment and block on that.
b) Close as a non-actionable bug. (Too much of a corner case.)

> The largest component is networkd, but it requires a lot of conffile
> shuffling, so I'm not sure it is worth the effort. For my own use
> cases, I actually want networkd everywhere, so that is not an itch I'm
> particularly eager to scratch.

Yeah, networkd tends to be useful in embedded. On the other hand putting
stuff that is related to sessions (s-logind, s-localed, s-update-utmp)
or diagnostics tools (s-analyze, s-cgtop, s-bootchartd) into a separate
package might make more sense? (Yes, still a lot of work.)

Helmut

[1] http://sources.debian.net/src/kmod/22-1/tools/depmod.c/#L2010