2012-05-27 4:15, Alasdair Lumsden wrote:
As project lead I can tell you that we won't be doing SPARC
> unless someone comes along and takes ownership of that project, > and we definitely won't ever be doing SVR4 packaging as long > as I'm project lead.
"No Bart, you cannot have the cookie now after all. Your mother made a very loud point!" (C) The Simpsons I think, supporting the minimal-interruption *migration* from legacy (SVR4) systems would be more important to me than an SVR4-based distro, especially if that option is so firmly fought against. However, comfortable migration "should" support running legacy local (fullroot) zone roots provided as-is (i.e. without IPS packaging), even if not directly supporting installation of such (SVR4) zones with OI. Do you loudly object even to that? Then to clarify: 1) SVR4 support: as I see - at the moment SVR4 are installable on OpenIndiana "as is", including the pre/post-scripts, which is good for those legacy users who can't/won't migrate for whatever their reasoning is. Is this going to remain in place, or are there plans to rip out pkgadd,etc. and still claim being "the upgrade path"? ;) One limitation that I see however, is that an SVR4 package installed in GZ does not get auto-installed/updated in LZ... Oh well, that's likely an IPS brand thing... 2) Is there a documented and/or scripted upgrade path for users of SVR4-based systems to export-import their zones into an IPS system (i.e. use same-named SUNW* package names if available via IPS and update them from an old SXCE/Sol10 image to the current OI baseline upon zone import)? Something simple, working in-place on (a clone of) the old zone dataset, and that would not require reinstalling the whole set of zones and manually migrating the settings, data, installed third-party programs (packaged or standalone)? To the very least, it would suffice if the SXCE zones just worked "as is" in OpenIndiana, allowing for quick upgrades of the host OS and little downtime for tasks-in-zones being upgraded later - alas, they don't, even after some hammering. 3) Regarding sparse-root zones: does the IPS theory firmly forbid the sparse-root zones with their benefits of faster provisioning, smaller footprint on disk/RAM/cache, fast propagation of OS-wide updates, and whatever else people liked about them? Or is it possible to tame IPS code into compatibility with the concept of sparse read-only rootfs (/usr, /lib...)? Thanks, //Jim PS: What is so inherently bad about SVR4 which is not bad in DEB, RPM, etc.? :) ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
