Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , 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 To: cygwin-apps AT cygwin DOT com Subject: Re: Keeping base, adding standard. Message-ID: <20020326132638.GA27571@redhat.com> Reply-To: cygwin-apps AT cygwin DOT com Mail-Followup-To: cygwin-apps AT cygwin DOT com References: <3C9FAE2B DOT 1070706 AT ece DOT gatech DOT edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C9FAE2B.1070706@ece.gatech.edu> User-Agent: Mutt/1.3.23.1i 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 >actions. 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 >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. 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. cgf