OK I see now. So it's performance overhead and it's uncommon utility
make it one of the things it makes sense to remove from a desktop-tuned
kernel. Ok no problem.

Then the question becomes, why, when I choose the "minimal text-only
system" during install, and make no other software choices, do I get the
desktop kernel instead of the server one? If that target isn't a
"server" target, what is?

It breaks LXC which requires it. All other LXC options are enabled in
the desktop kernel but the one can't work without the other so you might
as well turn the other lxc options off also, or turn cgroup on.

BTW, which are these options?

Got me there. I knew there were several options that needed to be
enabled and I knew they all were, but I hadn't actually gone over them.
I see now none of them look lxc-specific. Sorry for _that_ noise.

The problem with userspace packages depending on certain kernel features
or versions is that it doesn't really do what you want. You can express
a dependency on an installed package, but what really matters is the
running kernel, which rpm can't test for. Also if you depend on a
certain kernel flavor (or some virtual capability provided by some
flavors), the effect would be that the installer would install the
desired kernel flavor _alongside_ with the "wrong" flavor, because
different kernel flavors don't conflict with each other. Just something
to keep in mind.

hmm? I thought all along you could depend on say, a file, say, /bin/ksh,
and it doesn't matter how that file got there, rpm is satisfied. And if
it's not there, then one of the several possible packages that each
supply that file (bash supplies a symlink which is a lie and that I hate
that it does that..., and pdksh, and of course ksh93 (zsh too but I
don't know offhand if opensuse's rpm of it does) all also can supply
their own version of the same file. When it's missing and a package
depends on it, ... I don't know what happens. I'll go mock up a test now
and answer my own question.

Maybe what I can do is have the lxc package do a test at install-time in
%prein, toss up a message telling the user what to do, and then
abort/fail the install?

That way it isn't simply installable broken, nor do I force a bad
requirement of any specific kernel to the exclusion of any other.