Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Sun, 17 Jun 2001 22:40:15 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: Comments on Robert's category feature
Message-ID: <20010617224015.A27489@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF7A04 AT itdomain002 DOT itdomain DOT net DOT au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <EA18B9FA0FE4194AA2B4CDB91F73C0EF7A04@itdomain002.itdomain.net.au>; from robert.collins@itdomain.com.au on Mon, Jun 18, 2001 at 12:13:10PM +1000

On Mon, Jun 18, 2001 at 12:13:10PM +1000, Robert Collins wrote:
>>Ok, I've played with Robert's changes and I don't think that they go
>>far enough.  Has anyone else looked at them?
>
>There's plenty more to do.  A popup chooser to choose what packages to
>use to satisfy dependencies.  The ability to lock a package, so that it
>doesn't get autoinstalled - say when you have a custom automake on your
>system.  The question is how much is needed to ensure that a default
>install is useable, and that the existence of non-default packages is
>easily visible.  (So we don't get "I installed cygwin, but cannot find
>where it put gcc").

I think that if we have a few categories:

Default (or Core?)
Standard
Development
Graphics
XFree86

It might help.

With those, we should be able to get by for now.  I just don't like the
grouping of Category on the side.  I think that people will be confused
by it so I don't think that it is a good first cut at what needs to be
done.

Also, as a side effect of getting some of this info into setup.ini, we
could construct a web page that people could inspect to find out what's
what.  Also, we could use DJ's tar file browser to allow people to find
files and we could set up a search facility that would allow people to
search tar files a la rpmfind.net.

I know that we have an infinite amount of stuff to do but I just
want to get to the next level.

>Of those, I think the key one is the visibility of all the non-test
>categories/packages by default. 
>
>> I think we still need to change the chooser dialog so that it can
>> create different views.  The default view should just display 
>> categories.
>> Maybe categories should have those nifty chooser things so 
>> that you can
>> deselect the whole thing, use test versions for the category, download
>> sources for the category, skip the category, etc.
>
>At this point I was aiming for a simple-but-does-the-job approach. I
>think those nifty things fall into our laps when more of the background
>detail is implemented - for example per version dependencies and
>"features" provided per package. [De]selecting the category would be
>very useful now however.
>
>The reason for keeping it simply was to assuage my only concern : that
>we keep it fairly simplistic, until "someone" gets the time to integrate
>in the core algorithms from a mature packaging & dependency system.

Simplicity of the GUI doesn't have to be coupled with simplicity of the
dependency algorithm, though.  We can still display collapsing/expanding
categories in your current scheme.

I am going to be going away this week again.  I'll try to use my flight
times to come up with a proof of concept.

>I think the full/part button should be renamed to "view" and cycle
>between - full/part/categories.  That should be fairly intuitive.

Sounds ok.

I know that we are reinventing the wheel here and that is bad but I'm
not 100% convinced that using RPM or PKG is really the way to go here.
Maybe it's just because I don't currently know how to use their
interfaces or maybe I'm just not looking forward to making the interface
completely win32.

cgf