Michal Marek wrote:
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
Got it. So I can actually continue depending on kernel-default and it's merely a little inefficient in that it may sit there unused if the user has some other kernel that works. rpm will bring it in, but not make it the default and not remove the desktop one. Then I perform a cgroup test at run-time just so that when it fails I can put up a simpler message than what lxc-start will generate, that makes it as easy as possible to know what to do. Also perheps more importantly so I can avoid even trying to run lxc-start or lxc-execute which might leave a bit of a mess behind or hang etc. No test or failure at install time. Although a notice that doesn't require user input might be good even though many/most never see such. Lastly just make sure it's clearly documented in any likely place a person encountering the failure or looking to try using lxc for the first time might look. ie the main man-page and googled up docs. That part is already true. -- bkw -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org