On Friday 24 March 2006 23:02, Geoffroy Vallée wrote:
> Le Vendredi 24 Mars 2006 13:51, vous avez écrit :
> > I was not really asking to validate the patches, but simply to provide a
> > way to rebuild the kernel modules on the fly for these packages. If the
> > build bails then the user knows that it does not work.
>
> I do not see the benefit to diffuse something if you cannot say "it should
> work". And again according to me it is not possible to say "it should work"if
> you take any kernel patch and a random kernel version.
> Users can take SRPMS if they want to compile their own kernel. I also see the
> point to automatically compile modules because the kernel does not have to be
> modified but i don't think we can do that for a kernel patch (again a patch
> for 2.6.16 has a lot of chances to not be applicable to the 2.6.16 kernel
> provided by Fedora Core 5). At the end, we will be able to provide an
> "automatic compiling mechanism" only for a specific configuration. Then why
> not create a binary package?
>
> BTW, do we know for example if the DIPC patch may be applied to different
> kernels without conflicts? i know it is not the case for Kerrighed and
> Lustre.
I agree here with Geoffroy. This discussion is exactly what we need for
getting some ideas on a kernel-dependent packages infrastructure.
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
PS: I'll be away from my email for 1 week, appologies that eventual replies to
this thread will be very late.
-------------------------------------------------------
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&kid0944&bid$1720&dat1642
_______________________________________________
Oscar-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
