Erich Focht wrote: > 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? > Sorry for the late response. Yes, adding the additional attribute (let's say "kernel_class") to the table "Packages" is trivial. All I want to say regarding oda is ask if this attribute affects all the other packages. If so, it would be good to add it. Otherwise, we'd better create another package releated table like "Packages_rpmlists", "Packages_conflicts".
-- DongInn > 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 > ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
