Mail Archives: cygwin-apps/2002/03/26/08:26:44

Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Date: Tue, 26 Mar 2002 08:26:38 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-apps AT cygwin DOT com
Subject: Re: Keeping base, adding standard.
Message-ID: <>
Reply-To: cygwin-apps AT cygwin DOT com
Mail-Followup-To: cygwin-apps AT cygwin DOT com
References: <FC169E059D1A0442A04C40F86D9BA76008AB98 AT itdomain003 DOT itdomain DOT net DOT au> <3C9FAE2B DOT 1070706 AT ece DOT gatech DOT edu>
Mime-Version: 1.0
In-Reply-To: <>
User-Agent: Mutt/

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 -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019