Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on Robert's category feature X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Wed, 20 Jun 2001 12:33:55 +1000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Robert's category feature Thread-Index: AcD5L+rDjjhSKWR6QQet/Ds2Kupd+QAAIHyQ From: "Robert Collins" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id HAA28533 > -----Original Message----- > From: Brian Keener [mailto:bkeener AT thesoftwaresource DOT com] > Sent: Wednesday, June 20, 2001 3:44 AM > To: cygwin-developers AT cygwin DOT com > Subject: Re: Comments on Robert's category feature > > > Christopher Faylor wrote: > > >> I think that if we have a few categories: > > >> > > >> Default (or Core?) > > >> Standard > > >> Development > > >> Graphics > > >> XFree86 > > >> > > >> It might help. > > For some reason I had categories pictured in a whole > different light. At some > time long ago categories were mentioned in terms of such > items as shell's, > emulators, editors.... And while this does not lend itself > well to all > packages that was the light that I was thinking of categories in. There are really three things here: 1) preset templates for setting up a machine for development/xfree86 use/ and the like 2) marking each package as being of a particular type or category 3) ensuring that each package has what it needs to run. > I also agree with the above but see the above as more of a > broader category > (let's call it installation method - ie are you installing > just the core, a > workstation, a server, development system) - this is > something I see as > selectable from a installation method dialog whereas > categories are let's go > select a shell, let's go select an editor and so on. Sure. I agree with you. The point about "installation methods" is that they _require_ dependencies to operate. They don't _require_ package categorisation. The reason they require dependencies is that you are specifying a list of packages that need to be installed. That can be done in one of two ways: special code that turns on packages x, y, and z, or generic dependencies, and then have a meta-package that depends on the packages needed for the core/ a workstation/ a server/ a development system. > Then later on as we implement dependencies then you have - > sorry you cannot > install that emulator without this shell or whatever. > Just my $.02 cents worth. > > On a side note as well I tried to try the dependecies logic > using an update > from cvs and Roberts sample setup.ini - I don't see anything > different - where > is the categories. You will need chris's updated copy of my patch before anything happens to the setup.exe interface. The code in CVS is just the parser, not the operational logic. BTW: I'm about 50% through to doing the updated screen Chris suggested. I think that a third view, that selects the metapackages only will be quite useful (ie show Development Workstation Server and just let the user choose one of those) but one thing at a time. Rob > bk > > > > > >