jan damborsky wrote: > 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 >
Hi Jan, Thank you for the explanation! Joe
