Bart Smaalders writes: > Darren.Reed at sun.com wrote: > > David Bustos wrote: > > > >> ... > >> > >>> There's another secondary issue: currently, when a Solaris developer > >>> removes a service, the onus is on them to clean up all vestiges > >>> in the repository. Somehow, this feels wrong. > >>> > >> > >> Well he needs to worry about the dead root case, and that is wrong. > >> This is another symptom of not committing the repository format. We > >> need to implement a mechanism by which we instruct SMF to delete > >> a service on next boot, since we can't modify the repository before. > >> This is bug 6438829. > >> > >> > > > > Is there no way around the Windows philosophy of rebooting after > > every change is made to the operating system configuration? > > > > Can I file a bug on the solution you're suggesting to bug 6438829? :) > > This isn't a case of requiring a reboot. We need to be able to > update software that isn't currently running (eg a zone or alternate > boot environment, or upgrade from DVD, Xen instance, etc). In this > case, we need to defer repository changes until the OS instance that > was changed is run.
Yes. Runtime updates must be handled automatically, which was explicitly raised upthread by David as a gap in the "upgrade" method proposal. They're handled pretty much automatically by today's mechanisms (e.g. [i|r].manifest). Indeed, in most the runtime update cases are handled *better* than we handle the non-running image case. Thus, we've got a bug in the non-running image case. liane -- Liane Praza, Solaris Kernel Development liane.praza at sun.com - http://blogs.sun.com/lianep
