On Wed, 2006-12-06 at 17:59 +0000, Mark McLoughlin wrote: > On Wed, 2006-12-06 at 12:55 -0500, Jeffrey Law wrote: > > > What I haven't wrapped my head around is what advantages we really get > > from blasting down filesystem diffs over providing the clients with an > > update manifest. But I haven't really thought much about it. > > I think the explanation that makes most sense to me is the > "reduce/remove moving parts" thing. I can certainly buy that. > > By making the root filesystem read-only, and making the update > mechanism as simple as possible (on the client), you reduce the risk of > something breaking on the client. I wasn't envisioning changing that the read-only property of the root filesystem during normal operation. I think we'd both agree readonly root is a good thing. The root FS has to go R/W for the update for either scheme. Presumably we're sticking with the atomic update model where updates are applied at reboot time? Note that I don't see a lot of difference between capturing the FS and an update manifest. In the end they probably both look similar. Replace X with Y, remove Z, create Q. What changes are whether or not those represent files or packages. I think the key advantage of sending FS level updates over sending changes to a profile is the client doesn't have to execute arbitrary scripts found in RPM files. Jeff