Robert Mustacchi via smartos-discuss wrote:
The sparse nature of the zone, eg. that your /usr is from the GZ actually has very little to do with this problem and in fact makes the upgrade path easier when doing a platform update. Because the core libraries have to be in sync with the kernel, it means that you'd have to go and copy data around to every zone and manage that -- definitely not something we want to change.
That's a good point, I don't see how you could support whole root zones with the SmartOS way of doing upgrades!
The challenge with upgrading from one release to the next comes from the third party packages themselves doing things in incompatible ways. We can't guarantee that your favorite library will not change or break its ABI. In addition, there are painful things like when Dovecot change its configuration format, or when you end up having to cross a flag day in postgres where the version has an on-disk change. The problem is that there are so many different packages and upgrade challenges to come across, that it can be really quite difficult just to enumerate and test them all. Do we write software to automate all of those cases, what do you about the cases where you can't do that, etc.?
I've often wondered how much time oracle have to spend validating IPS packages across SRUs. I guess that's why they do release SRUs as a set rather than individual patches.
Kernel zones are handy get out of jail free card here. They would be a much better fit in SmartOS than whole root zones.
-- Ian. ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
