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 Date: Sun, 23 Sep 2001 09:34:15 -0400 From: Christopher Faylor 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