On Thu, Jul 31, 2008 at 12:40:39AM +0200, Bastien wrote: > It's not that important anyway. It just occurred to me that the > dependancies management challenge could be somehow dealt with by > delivering a set of default activities. I'm not aware of any > software distribution drawing such a strong line between the > "core system" and the applications/activities. >
We have been managing the dependency issue by ensuring that the 'core' activities required for a given build all work on the system-level software packages we include. To my knowledge this verification has been done manually. We could better share our efforts by working to make sure that a given activity simply lists the correct set of dependencies, pushing this data to a package repository, and supporting deployments as they cherry-pick their requirements from it to construct new images and push their products back into it. The separation between system and application-level software is a core roadblock in our integration of more intelligent package management policies. How can an isolated user-level package management application be allowed to modify system-level, shared, code that will affect other applications from which it is supposed to be isolated? A unification of system and application-level software package management thus violates our security model. The user-level application isolation required by this security model serves to enable easier code sharing between children. It also makes it easier for sysadmins to accept the use of relatively untested software packages on the XO. We can probably all agree that the separation between system and application software is useful for security and the execution of untrusted code. Can we reasonably work around this distinction to allow the management of both sets of software as one whole? Erik _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel