> But so does a single kernel package that includes the modules. There > can be no risk of having modules mismatch the monolithic kernel then. > Nor will changing to this model "destabilize" anything, the package is > sticking things down /lib/modules same as the modular packages do > using > the same code in the packaging app. >
okay good point, i see what you are saying. i guess the only negative to this is that people will start getting modules they're never going to use .. > Current setup seems unstable IMO because it indirects through the > whole > packaging system, bloating the work done there. The only thing that > makes sense about it is that is reduces footprint on storage when we > consider all the modules, but bulk of users do not want to have to > care > about package selection to this degree, they will go with whatever > default package set is. > well another thing is i could write an app that has a dependency on a module, and get it pulled in for me by the package dependencies, i suppose? > Anyway this is up to the packaging guys, but I would stick it all in > one > package and have done with it, making folks' updates faster as a side > effect. > glad we're discussing this! ; -- Jay Vaughan _______________________________________________ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support