Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Date: Sun, 23 Sep 2001 09:34:15 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com, cygwin-apps AT cygwin DOT com
Subject: Re: new 'temp' directory in CVS cinstall contains dependency WIP
Message-ID: <20010923093415.D28032@redhat.com>
Reply-To: cygwin-apps AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com, cygwin-apps AT cygwin DOT com
References: <20010919225819 DOT A26863 AT redhat DOT com> <0a3f01c1441a$948e0b60$0200a8c0 AT lifelesswks>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0a3f01c1441a$948e0b60$0200a8c0@lifelesswks>
User-Agent: Mutt/1.3.21i

On Sun, Sep 23, 2001 at 08:29:08PM +1000, Robert Collins wrote:
>> "rh" is a perl script.  If you say "rh -d setup.ini.base > setup.ini"
>> it will create a setup.ini that is loosely based on debian categories
>> and descriptions.  setup.ini.base is any setup.ini created by DJ's
>> update-setup script.  I've recently posted a pointer to this script.
>
>Where? I couldn't find a pointer for "update-setup" in the recent
>history for cygwin-apps or -developers. I'll work on the presumtion that
>it is the script that reads setup.hint and the files and creates
>setup.ini from that.

I posted a URL to update-setup recently, possibly in cygwin-apps.

I'm not sure why you are referring to it, though.  The setup.ini that
update-setup produces is the same old setup.ini that is currently in
use.  The "rh" script works on it to produce a categorized version.

>> Without the "-d" the rh output is based on Red Hat's rpms.  You do need
>> to have all of the packages on your system that are in the cygwin
>> release to use this, though.
>
>As I understand rh, it's meant to post process the output of DJ's
>update-setup to create a categorised environment. I think this is the
>wrong approach. I don't think we should be generically pulling in either
>the rpm or debian information. (However, as a kick start for the meta
>data it's ok, but not long term).

No.  I just wrote the script to provide a baseline that we could use
going forward.  I did want it to be as robust as possible so that I
could use it to regenerate things in case of a catastrophe but I don't
think that it will ever be used again after this initial go around.

That's why the script is in a "temp" directory.

>Possible option: As a use for "rh", how about we have it create
>setup.hint files if they are missing, rather than a setup.ini. Then we
>tweak those files by hand. It means that there will not be constant
>tweaking of a script as things change. Maintainers can take
>responsibility for putting things in the right category and
>dependencies.
>
>Long term the packages should have the metadata in them, so that local
>packages auto assemble into the correct categories.

See above.  I only wanted people to change the script so that I
could easily regenerate setup.ini in the next two weeks, or whenever
we release the new version of setup.exe.

I wasn't trying to open up a discussion of where the data would be
stored.  That ship has sailed.  I sent a message about this weeks
ago which had no discussion, IIRC.

>> The generated setup.ini file currently causes setup.exe to SEGV.
>> It seems to get about as far as calling add_required for the ncurses
>> package and then it starts recursively calling insert_pkg, for some
>> reason.  It would be great if someone could debug this.
>
>"Works for me". Is the included setup.ini the one that crashes your
>setup? If not, what exact options are needed to create the fault - or
>better yet can you post the fault ini?

Yes.  The setup.ini in CVS is the one that failed.  That is why I included
it.  I guess I'll have to debug this further.

>> If you think you have a good idea but you don't wipe out a previous
>> version of a setup.ini or rh file, feel free to add a new file to
>> this directory for everyone's amazement and delight.  As I said,
>> I'll probably delete this directory eventually anyway.
>
>Well my good idea is basically to delegate the responsibility and
>authority to maintaing the category and depenency stuff to the
>maintainers. IMO that solves the problem in one hit. We allow 1 week for
>all the maintainers to create setup.hint files with category and
>requires lines. At the end of the week we put up the new setup.exe.

Or, the maintainers could change the setup.ini file as I suggested.
I don't see that it makes a big difference except that I can delay
adding the parsing of extra fields in update-setup.  If you create
a setup.hint file in contrib/latest with the new fields now it is
possible that update-setup will croak.

Since I've gotten almost no response to my request that people inspect
the dependencies in setup.ini I think we'll actually sail by the
week mark very soon, anyway.

I actually expected that almost no one would respond and this is
exactly why I wrote the script.  Otherwise, I'd be sending out
"Please update your package info!"  "Really!"  "Come on!" mail
for the next four weeks and would just end up doing it myself.

This is the second or third time that I've asked for updates
and only a small percentage of package maintainers have responded.

cgf