Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
From: "Gerrit P. Haase" <gp AT familiehaase DOT de>
Organization: Esse keine toten Tiere
To: cygwin-apps AT cygwin DOT com
Date: Wed, 17 Oct 2001 10:24:16 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: New setup.ini is operational
Reply-to: cygwin-apps AT cygwin DOT com
Message-ID: <3BCD5C50.11556.55FDC5CD@localhost>
In-reply-to: <20011016191041.A30365@redhat.com>

Christopher Faylor schrieb am 2001-10-16, 19:10:

>I've put up a new setup.ini on sources.redhat.com which has all of the information
>that people have submitted over the last few weeks.
>
>(Hmm.  Now that I think of it I may have missed Rob's changes to squid if he
>made them to setup.hint.)
>
>Currently most of the package information lives in setup.ini.  I expect
>that, over time, people will slowly migrate info to setup.hint in their
>respective application directories.  The tags and layout for setup.hint
>should be the same as for setup.ini.  setup.hint takes precedence over
>setup.ini, as always.

setup.ini:
@ newlib-man
sdesc: "Man pages for some system functions"
category: Doc
requires: "cygwin man"

@ w32api
sdesc: "Libraries and headers for Win32 API"
category: Libs

w32api setup.hint:
curr 1.1-1
prev 20010520-1

setup.exe (2.78.2.13) offers me w32api-20010520 as new package now,
though I have w32api-1.1-1 installed.

BTW, is it possible to post a 'reference' setup.hint file here, with 
all optional contents?

>I've also upgraded setup.exe to use a much larger "chooser" screen so that
>you can actually read the short package descriptions.  I haven't upgraded
>to the latest category/dependency version of setup.exe since I thought that
>people would want the chance to play with things first.  There will be a
>lot of questions and confusion when we release the new version of setup.exe
>so we need to make it as bulletproof as possible.

I want to suggest a second time to use shorter category names, e.g.
'System Environment/Daemons' or 'System Environment/Libraries', wouldn't it
be enough to rename them in 'Daemons' and put openssl in 'Libs' && 'Devel'?
Also I don't like the split into 'Base Libs', 'Libs', 'Base', why not put
termcap in 'Base' && 'Libs', ditto 'Base Shells', we have 'Base' and 'Shells'
so put them in theses two categories, why a third category?
Ditto with 'Graphics Libs', 'Devel Libs' && 'Libs Text'
Every now and then someone will come up and claim:  
"My package doesn't fit in one of that categories, it is more of a 
'Net/Web/Superdaemon with GUI' and we need another category."

So, keep the names short and if there are packages that doesn't fit in one
of the categories, there probably soon will be a 'Misc' category.  And there 
are the short descriptions if someone needs to know what a package does, there
should be mentioned everything important.

>I would like to get out of the setup.cc modification business.  So once
>this is unleashed, I'll try to go back to no-setup-modification mode.  I
>do know that there is some strangeness with installing from local directories
>currently that I need to look into, since I broke it.
>
>Eventually, however I would love for someone to tell me that they think
>that setup.exe is ready for prime time.  If there is consensus when that
>happens, I will make a new release of setup.exe.
>
>cgf
>


-- 
=^..^=