Dear Kamran, I do not agree because:
1/ When you distribute a patch for a kernel modification, the patch targets a specific version of the kernel. For example, I do not think it is possible to have a patch for both 2.6.12.x kernels _and_ 2.6.16.x. At least you cannot assume it even if your patch is not intrusive. Moreover, do not forget that Linux distributions do not ship the official kernel. For instance, you have no guarantee your patch will apply on the Fedora Core 5 kernel (see current discussions about the "2.6.16 FC5 kernel" available before the "official 2.6.16 kernel" and the number of applied patches). 2/ you can create a package for each kind of architecture (x86, ppc and so on). Actually Linux distributions use this approach to ship a kernel: they identify their constaints and their needs and then package different binary packages for each processor types (SMP vs. non-SMP, x86 vs. x86_64). I do not see a real point to not follow the same approach. Moreover, i do not see the technical difficulty to create a package for DIPC regarding my experience with Kerrighed. It is exactly the same thing than create a package for the kernel for a Linux distribution. Do not forget rpm tools know how to deal with patches. Regards, Le Vendredi 24 Mars 2006 12:26, Kamran Karimi a écrit : > Thanks Geoffroy. I've been looking at Kerrighed's packaging, and it seems > that creating an RPM is not suitable for systems like DIPC and Kerrighed. > The reason is that installing such systems requires patching the kernel. I > see the following problems: > > 1) Including a pre-compiled kernel forces others to use a specific version > of the kernel, with whatever options that were selected at the compile > time. When distributing a patch, chances are users can apply it to a > similar kernel. DIPC's kernel patch in particular is fairly small and > non-intrusive, so chances are it can be applied to other kernel versions. > > 2) DIPC can work on non-x86 CPUs, so distributing an i386 RPM is > restrictive. > > Yes, for a user-level system, an RPM distribution is excellent. I won't > speak for Kerrighed, but creating an RPM for DIPC seems to complicates > things more than it helps. > > Maybe I need to be educated on the merits of creating an RPM for a system > like DIPC > > -Kamran > > > > > ------------------------------------------------------- > 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 -- Geoffroy ------------------------------------------------------- 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
