Hi, I saw no comment to this email. Maybe I'm overestimating the importance of kernel-dependent infrastructure, maybe not. Right now I think that without it OSCAR will not be able to keep up with new developments and it will be harder and harder to keep add-ons like SSI-OSCAR or filesystems or additional interconnect drivers (all depending somehow on the kernel version) in sync with OSCAR.
Concrete questions: Geoffroy, do you think that adding a "class" attribute named "kernel" or "kernel-module" (as proposed below) and some related infrastructure will satisfy your needs for SSI-OSCAR (and alike)? What more do we need? "class" is a bit too general and not specific enough for the purpose. Anyone another proposal for what this should be called? DongInn, is adding this additional attribute to the packages table realistic. Or should this be done differently? Any idea what effort the addition of this (and modification of related functions) would require? IMO the main changes we need first are in the package selection part, such that "kernel" packages are exclusive. And the "provides/requires" are considered correctly. Sure, there are not many packages really requiring this, but the current solution is _manual_ (I MUST know what I do when I install SSI-OSCAR). I'm afraid without this kind of infrastructure there will be no big motivation to add kernel dependent packages, because each of them will come with yet another set of workarounds... Regards, Erich On Saturday 25 March 2006 00:24, Erich Focht wrote: > Kernel dependent packages will not work for every distro. This is why we need > to have a distro filter at the package level in config.xml (it is of no use at > the rpm level). The package should simply be invisible if we are on the wrong > architecture/distro. > > IMO kernel dependent packages can come in two flavors: > - rebuildable kernel modules, for example Myrinet, DRBD, PVFS > - should come with a post_configure script which builds the modules > - we need some API step to recognize the need to rebuild the modules and > redistribute them to the clients/image if we update the base kernel > > - special patched kernel > - handled by kernel-picker > - currently not mixable > > In addition of course there will be user-space packages. > > These two cases need to be handled differently. In the first case one can > update the kernel and can use almost arbitrary kernels. These packages can be > mixed and coexist with other packages of this class. > > OTOH special kernel packages are not mixable, you can not use Lustre and DIPC > together except you make the effort to build a special kernel which supports > both. In this case it makes more sense to separate kernel and user space tools > into two separate packages. For example: > > lustre-userspace : requires kernel:lustre capability > dipc-tools : requires kernel:dipc capability > lustre-kernel : provides kernel:lustre > dipc-kernel : provides kernel:dipc > > If we select the lustre-kernel opkg we should only be allowed to select the > lustre-userspace opkg, but not the dipc-kernel or dipc-tools. But if somebody > creates a special lustre-dipc-kernel package providing both lustre and dipc > capabilities, we should be allowed to select both userspace packages. > > So what we could do is following: > > OSCAR packages should get a "class" attribute which should be one of: > userspace : pure userspace package > can "require" a certain capability. > > kernel : pure kernel package. At most one of these can be installed in > an image! These are mutually exclusive! > Can provide capabilities needed by userspace packages. > > kernel-module : contains script to automatically build module, > depends on kernel version, needs to be rebuilt for new > kernel, can contain userspace tools. > Can also provide capabilities. > > All packages should be subject to distro/arch filtering at config.xml level. > > If this sounds sane maybe DongInn could add this attribute to the packages > table. Then we could later figure out how to deal with the exclusion > conditions. > > Best regards, > Erich ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
