On Fri, 27 Jun 2008, Michael Stone wrote: > On Fri, Jun 27, 2008 at 02:50:34PM -0400, Erik Garrison wrote: >> Existing package managers (e.g. apt, rpm) do exactly what we want and >> more. Furthermore they are extensively tested and well documented. Why >> have we locally manufactured and promoted the square wheels of >> olpc-update and copy-nand? > > We chose a monolithic update solution because of several deficiencies, > *for our primary use case*, of all package-based upgrade solutions with > which we were familiar at the time. Package-based update solutions with > which we were familiar: > > * can leave the system in an inconsistent or even unbootable > state on failure. > > * ask users questions during the update process. > > * are not adequately bandwidth efficient. (They make no use of > bitpatterns which are already available on the target system.) > > * do not adequately verify the integrity of the resulting filesystem. > (We have actually detected two filesystem data corruption bugs as a > result of carefully auditing our filesystem consistency via the > update process.) > > * do not innately offer the user a 'big undo' button that permits the > user to try out large changes with confidence that they can easily > return to previous system states. > > These were some of the considerations that led to the development of the > olpc-update technology. > > Now, clearly, there are several technically adept users who would like > to be able to use their favorite package management tools to consume our > software. We _are_ interested in supporting this use case, for example > by modifying our build procedures to produce package repos 'suitable for > use in upgrade procedures'. The hard question is: "what more can we do?" > > Do you have other thoughts on either: > > 1) other ways that we could address the aforementioned inadequacies of > package-based updaters for our use case?
based on my knowledge of them I would not depend on them for your primary use-case > 2) other things we can do to integrate package-based updaters into our > current system? one thing that would be handy is if a machine with a developer key would look in a specific place in /home for a list of packages to install in addition to the image. It could then install these packages (either via the net, or via local .rpm files) I suspect that you are using them heavily to create the snapshot images for your current system. If this is the case, and you are willing to package all your small changes/tweaks to the system as a package (which could be a non-trivial amount of work. on my systems it's enough that I don't do it) you could then make the resulting config available to the net for users who wanted to take the risk to update from. I don't know rpm/yum (my main work is on apt based systems), so I don't know exactly what the terms are for the main repository, but it would need to provide the rpms and host the index of what's what so that the systems that query it would learn what packages are availabe, and be configured to install anything that's available from that source (it would need to not do so to an alternate repository, such as the RedHat one the build currently points at) David Lang _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
