Hi Joe,
On 03/18/09 12:34, Joseph J VLcek wrote: > 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 > > Jan, > > I have only one "suggestion". It just helps me when symmetry is used > for naming these types of things. > > What do you think about using the name <ai_add_packages> instead of > <ai_packages> ? > > This name would create symmetry with: > <ai_add_packages> > <ai_remove_packages> > > Just a suggestion. This is a good point - I was thinking about this and I agree with you that this naming makes more sense. The issue I could see here is that renaming ai_packages to ai_add_packages would introduce more incompatibilities. Then old AI manifests would no longer work with new AI image even if it contained list of packages to be installed and old AI image would not work with new AI manifest. I am not sure what the current strategy is as far as compatibility is concerned. The part of the problem is that we don't have support for versioning implemented - that would mitigate the problem in such a way that we could provide user with appropriate information - in this particular case that provided AI manifest is not compatible with given AI image. Thank you for your comments ! Jan
