Mail Archives: cygwin-apps/2002/03/26/08:26:44
On Mon, Mar 25, 2002 at 06:09:31PM -0500, Charles Wilson wrote:
>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.
I was wondering if someone was going to point to an existing
implementation that uses that plan.
>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
Apparently a handful of people find this confusing, however. See the
recent cygwin-xfree discussion where someone was quite upset when it
took them so long to figure out that setup.exe was both a floor wax
and a dessert topping.
>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".
Good point. So good that I was holding this response in reserve for
when the observation was raised.
>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...
Yes, this has bothered me, too.
>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
>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.
I'm still not convinced about the meta packages. I don't know if this
is my bias against things that I think will cause increase in mailing list
traffic or just personal irritation about having to wade through one
more screen during setup.
- Raw text -