Hi Ethan,
On 03/18/09 18:01, Ethan Quach wrote: > Jan, > > I like the underlying concept of complete observability to > the user of the list of packages to be "added" and "removed", > but is it premature to push what we've got now to the user-level > AI manifest? A valid answer is no, but I just want to make sure > its been considered to keep the lists internal for now, since our > current list is a bit awkward. I think that even if the current package list is not quite polished as it has to take into account existing deficiencies, it might be better to make those changes now, since then we will not need to continue to be aware of this problem in future. Also, I feel that making this change might help with our effort to provide consistent user experience for DC and AI, since DC provides those lists of packages in DC manifests. Thank you, Jan > > > thanks, > -ethan > > > jan damborsky wrote: >> Currently, if system is installed using Automated Installer >> with default list of packages, slim_install metacluster is >> left on the system - this prevents user from removing >> any package, since slim_install depends on all of them: >> >> # pkg uninstall SUNWgui-install >> Creating Plan /pkg: Cannot remove >> 'pkg:/SUNWgui-install at 0.5.11 >> <mailto:SUNWgui-install at 0.5.11>,5.11-0.109:20090305T193146Z' due to >> the following packages that depend on it: >> pkg:/slim_install at 0.1 >> <mailto:slim_install at 0.1>,5.11-0.109:20090305T202838Z >> >> As slim_install serves no purpose on installed system, it should be >> removed. Please see bug 3398 for details. >> >> For LiveCD case, Distribution Constructor (DC) takes care of removing >> slim_install/babel_install once 'proto area' is populated with >> packages. Following implementation is used: >> >> [1] DC manifest specifies list of packages to be removed: >> ... >> <!-- >> Packages to be removed from the pkg_image area before >> bootroot construction >> --> >> <post_install_remove_packages> >> <pkg name="slim_install"/> >> </post_install_remove_packages> >> ... >> >> >> [2] transfer module takes that list and removes packages from 'proto >> area' >> >> It seems we should follow the same approach for AI in order to >> provide user with consistent experience: >> >> [1] AI manifest would be enhanced, so that list of packages to be >> removed >> can be specified there >> >> [2] transfer module would read the list of packages and remove them from >> installed system right after IPS install phase is finished. >> >> [add 1] proposed implementation >> ------------------------------- >> In current AI manifest, following tags are used to specify list of >> packages >> to be installed: >> ... >> <ai_packages> >> <package_name> >> ... >> </package_name> >> </ai_packages> >> ... >> >> Based on this and in order to reflect the approach taken in DC, >> following tags would be introduced for list of packages to be removed >> >> ... >> <ai_remove_packages> >> <package_name> >> ... >> </package_name> >> </ai_remove_packages> >> ... >> >> issues to be addressed: >> >> [a] default behavior >> -------------------- >> I think that user expectation would be that if list is empty >> (no package name provided), nothing should be removed. Opposite >> approach would cause problems in situations where user installs >> customized list of packages in which case nothing is to be removed. >> >> The problem is that it is inconsistent behavior with respect >> to the list of packages to be installed - currently, if this >> list is empty, following packages are installed by default >> (as specified in ai_manifest.defval.xml): >> >> SUNWcsd >> SUNWcs >> slim_install >> entire >> >> One possibility is to change this behavior (don't use default >> list of packages) and if no packages are specified for the installation, >> nothing will be installed. It might look like it doesn't make too >> much sense to call AI to install nothing, but I think this would >> give us more flexibility. >> >> e.g. let's assume that AI engine will support more than just IPS >> transfer mechanism (like some method of fast provisioning), then >> empty list of packages would just mean that IPS transfer phase >> is not involved. >> >> With respect to this, following changes are to be proposed: >> * move default list of packages from ai_manifest.defval.xml to >> default AI manifest. >> >> Another advantage is that it is also less confusing, since user >> knows what will be installed just by taking a look at default >> AI manifest (no need to inspect ai_manifest.defval.xml). >> >> And this approach would be consistent with the one followed >> by DC. >> >> Then default AI manifest would be enhanced in following way: >> >> ... >> <ai_packages> >> <package_name> >> SUNWcsd >> SUNWcs >> slim_install >> entire >> </package_name> >> </ai_packages> >> <ai_remove_packages> >> <package_name> >> slim_install >> </package_name> >> </ai_remove_packages> >> ... >> >> And ai_manifest.defval.xml might be changed in following way: >> >> <default nodepath="ai_packages/package_name" >> from="value" type="element" missing_parent="skip"> >> SUNWcsd >> SUNWcs >> slim_install >> entire >> </default> >> >> -> >> >> <default nodepath="ai_packages/package_name" >> from="value" type="element" missing_parent="skip"> >> do_not_install_any_package >> </default> >> <default nodepath="ai_remove_packages/package_name" >> from="value" type="element" missing_parent="skip"> >> do_not_remove_any_package >> </default> >> >> >> >> * if list of packages is empty, AI engine will not install (or remove) >> anything. Since at this point there is no other mechanism >> implemented for installing bits on target, AI would just >> inform user and exit with error, since running rest of install >> (ICT) doesn't make sense. >> >> If going this way, following problem with compatibility will occur: >> * when new AI image and old default AI manifest were used, >> AI engine would not install anything. I am not sure if this is >> acceptable or if we should mitigate the problem in some way. >> >> Old AI image and new default AI manifest would work in the same >> way as old AI image and old default AI manifest. >> >> [b] What to install by default - slim_install/babel_install >> ----------------------------------------------------------- >> >> Currently, AI installs slim_install by default. Since it seems >> that we will be able to switch to one LiveCD media containing >> everything, the suggestion was made to accommodate AI behavior >> accordingly to reflect this change. >> >> Do we happen to know at this point which metacluster will remain >> after this change happens - slim_install/babel_install ? >> >> If babel_install, might it make sense to switch to babel_install >> in AI now ? >> >> Please let me know, what you think about this. >> >> Thank you very much, >> Jan >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
