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 Message-ID: <3C9FAE2B.1070706@ece.gatech.edu> Date: Mon, 25 Mar 2002 18:09:31 -0500 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Robert Collins CC: cygwin-apps AT cygwin DOT com Subject: Re: Keeping base, adding standard. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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