Mail Archives: cygwin-apps/2002/03/25/18:07:29
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
- Raw text -