Keeping base, adding standard.

[Charles Wilson]

Robert Collins wrote:


>>Again, you're inventing another layer that I maintain will 
>>only confuse things.
>>
>  
> ...
> 
> I see your point. I can articulate the difference but I'm not sure it
> helps the on-screen UI issue. A category is a attribute of a package.
> 'bash is a shell'. Something like the standard collection (which I agree
> we need) is a collection of packages to serve a particular type of user,
> rather than an attribute of the packages. It's my belief that we will
> run in management headaches with the categories if we take the approach
> of changing the package attributes rather than storing the collection as
> it's own descrete 'thing'. As I've said however... there are ways and
> ways.

Red Hat Linux's installation (used to, perhaps still does) separate the 
concept of "Installation Type" and "Individual Package Selection". 
You'd pick "Workstation Install" and that would preselect a bunch of 
pacakges, or you'd pick "Server Install" and that would preselect a 
different set of packages.  Of course, there was ALSO the option of 
continuing to the detailed package selection step, where you could 
override those choice: don't install some packages that were 
auto-selected by the Installation Type choice, or DO install other 
packages that were not auto-selected.

This seems to correspond somewhat to Rob's position.

Mandrake does it slightly differently: they have an initial page of 
"Categories" where you can select "Multimedia Apps" or "Scientific Apps" 
or "Office Tools" or "Servers".  These choices will auto-select certain 
individal packages, but there is (again) a second more detailed page in 
which you can override these auto-selections -- add some packages, 
remove others.

This seems to correspond to Chris's position (in that you pick 
categories, not installation type, in the initial step).  However, both 
RH and Mandrake use *two* screens for this purpose; Chris wants it all 
done on one screen.

However, these analogies overlook one important point: you only use the 
Red Hat installation program or the Mandrake installation program ONCE; 
when installing the system.  You use a different set of tools for 
maintaining/updating the system.  We use the same tool for both actions. 
  This is BOUND to influence the way the UI is developed.  Some things 
make more sense to be presented in one view during "installation" -- but 
that same 'view' is less intuitive when "updating".

OTOH, it really irks me on mdk/rh that the tools are different: I often 
wish, after installing, that I had checked the 'office tools' category 
-- but now I have to use this OTHER tool, and explicitly select the 
various office tools that WOULD have been auto-selected as a group if 
I'd done it during the mdk installation...

The point: previous UI's use two different pages for 'overall selection' 
and 'detailed control'.  I think that is a good idea -- and is not 
necessarily confusing to new users.  Whether so-called 'clickable 
categories (shells, libraries, utils, etc)' go in the initial page, or 
'installation types (base, standard, development, all)', seems to be a 
matter of taste.  However, having both would definitely be confusing:
   base standard development shells libraries utils

Q: if I select 'standard', do I get any shells?  Do I need to select 
'standard' if I've chosen 'libaries' and 'shells' and 'utils'?

So, I come down on the side of:

   'coarse selection page':
      only meta-packages appear.
        meta-package definition: a 'package' that appears
           only in setup.ini, and has no actual -src.tar.bz2
           or .tar.bz2.
        meta-packages depend on ACTUAL packages (or other
           meta packages)
        suggested meta-packages:
           base, standard, developer, all
        (I don't like this, but there's no reason you couldn't
           also have 'shells', 'utils', etc, that correspond to
           our existing categories.
        How are meta-packages added into setup.ini?
           cygwin/meta/base/setup.hint
           cygwin/meta/standard/setup.hint
           (e.g. just like regular packages, but upset2 will
           have to be modified to accept the meta/ directory,
           and to accept "packages" with no tarballs)
        What about meta-packages that correspond to categories
           (if we want 'em)?  Another script that autogenerates
           cygwin/meta/Util/setup.hint by parsing
           cygwin/latest/*/setup.hint and cygwin/contrib/*/setup.hint
   'fine selection page':
      meta packages do NOT appear (although clickable categories do work)
      roughly the same as the current chooser.

--Chuck