Mailinglist Archive: opensuse-kernel (131 mails)

[Michal Marek <mmarek@xxxxxxx>]

On 18.2.2010 08:06, Brian K. White wrote:
> Michal Marek wrote:
> > On 16.2.2010 21:44, Brian K. White wrote:
> > > Hi,
> >
> > Hi Brian,
> >
> > please use the opensuse-kernel mailing list (an pick a better subject
> > next time...). I also added Jiri, who maintains the lxc package in Factory.
>
> Ah sorry the web link on the OBS page autofilled that and I never even 
> looked at it.
>
>
> > > cgroup support is missing from the desktop kernel. Is this intentional
> > > or accidental?
> >
> > Intentional, see https://features.opensuse.org/305694 and
> > http://gitorious.org/opensuse/kernel-source/commit/c065c52q1 .
>
> 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 ...

The difference is that if you have a script that needs /bin/ksh, the
package manager will install ksh alongside with bash and your script can
use it right away. Now if you depend on a certain kernel flavor, the
package manager will install that flavor alongside with kernel-desktop,
but your package won't work until the user reboots into the right kernel
flavor. So you have to handle missing kernel features in the application
anyway.


> 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.

Please don't fail %pre/%post scripts intentionally. Displaying an error
message is fine, but if the script fails, then you'll just annoy users
who launch install of several packages and expect it to work unattended.
Also you should print the error message in the init script, because as I
said above the installed kernel is not necessarily the running kernel.

Michal
-- 
To unsubscribe, e-mail: opensuse-kernel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kernel+help@xxxxxxxxxxxx