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.

Joe

Reply via email to