Mail Archives: cygwin-developers/2001/06/17/22:40:21
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
- Raw text -