Erich Focht wrote: > On Saturday 22 April 2006 22:26, DongInn Kim wrote: > >> 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". >> > > Meanwhile I'm not so convinced any more that the opkgs should bear the > additional info on their nature (kernel/module/userapp) in a separate field. > For 5.0 we can probably live with it the way it is. > > But we can multiplex this information into the "Provides" and "Requires" info > for each opkg. I don't know whether there is a clear resolution of > opkg-provides and opkg-requires, similar to binary packages. (Maybe add > opkg-excludes). If not, we need it, I guess. I think this would be flexible > enough for handling the kernel/module/userapp issue. For example: > - a kernel opkg: > - provides kernel:lustre > - excludes kernel:* (means: no other kernel:* package can be > installed at the same time) > > - a user application requiring the lustre kernel: > - requires kernel:lustre > > - a module opkg: > - provides module:pvfs > > So: do we have a provides/requires/excludes resolution? Can it be extended to > handle something like "kernel:*"? > Hi Erich,
We have not set up this feature like kernel/module/userapp dependent packages stuff. But somehow we can re-use the current tables "Packages_requires" "Packages_provides" to implement the "Provides" and "Requires" thing for kernel/module/userapp dependent packages. mysql> select P.package, R.* from Packages_provides R, Packages P WHERE R.p1_id = P.id; +---------+-------+---------+---------+ | package | p1_id | p2_name | type | +---------+-------+---------+---------+ | lam | 14 | mpi | package | | mpich | 23 | mpi | package | +---------+-------+---------+---------+ 2 rows in set (0.00 sec) mysql> select P.package, R.* from Packages_requires R, Packages P WHERE R.p1_id = P.id; +---------+-------+------------+---------+ | package | p1_id | p2_name | type | +---------+-------+------------+---------+ | pvm | 5 | switcher | package | | opium | 11 | sync_files | package | | lam | 14 | switcher | package | | mpich | 23 | switcher | package | +---------+-------+------------+---------+ 4 rows in set (0.00 sec) mysql> So, we can set the type (kernel/module/userapp) for the corresponding packages like in the above tables. For excludes, we may need to create another table. Let's say "Packages_excludes" and do the same thing. What do you think? Regards, - DongInn > Thanks, > best regards, > Erich > > > >> -- 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 >>>> > > > > > ------------------------------------------------------- > 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 > ------------------------------------------------------- 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
