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:*"?
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
