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 List-Subscribe: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Message-ID: <0a3f01c1441a$948e0b60$0200a8c0@lifelesswks> From: "Robert Collins" To: , References: <20010919225819 DOT A26863 AT redhat DOT com> Subject: Re: new 'temp' directory in CVS cinstall contains dependency WIP Date: Sun, 23 Sep 2001 20:29:08 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 23 Sep 2001 10:37:08.0184 (UTC) FILETIME=[B1DB7580:01C1441B] ----- Original Message ----- From: "Christopher Faylor" > I've checked in a new 'temp' directory in the sources.redhat.com > repository. It contains the tools I used to create a populated > setup.ini. I'm assembling a little TODO list. it's pulled from my comments in this email + a quick review of setup.exe. Chris, if you could comment on this list - is anything missing, is anything inappropriate. I propose that the net contributors use this TODO to get a category/dependency based setup "out there". So far: 1) show both package name and description. or provide a popup with the description it. Something anyway. 2) Alter update-setup (if needed) to allow listing of category and dependency information. As I understand it's operation, the contents of setup.hint are copied verbatim so no changes should be needed. 3) create a complete list of allowed categories. 4) create initial setup.hint files for every package. (delegated to the maintainers). > "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. > 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). 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. This gives up instant short term metadata in setup.hint for every package and we should review that and then consider it authoritative. That metadata will then become the responsibility of the maintainer to keep up to date. We should have an authoritative list of categories as well. Long term the packages should have the metadata in them, so that local packages auto assemble into the correct categories. > 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? > I'm also open to other category names. You can see the ones that > I/Debian used in setup.ini. I suggest we agree on the TODO at the top, and then visit this as a specific item. I'm partial to debian too :]. > As I was setting up the category names I could hear the cygwin mailing > list voices asking "Why is gawk in the base category!!!??? I don't like > gawk! It sounds like someone is vomiting!" I'm wondering if our category > method will immediately prove that we really need something as > sophisticated as rpm or apt. Debian has gawk in base, because it's needed to operate some of the apt update-foo scripts. I think the answer to that is the same as our current one "we do not support a setup without foo". I.e. we will likely end up with a very similar list of minimim packages needed for the post- and pre-install scripts to operate properly. > I was also wondering if we wanted to have a minimal category, too, which > only included bash, cygwin, ash, and...??? That would be the "Required" hard coded category. The name can obviously be changed. I'd have said that it becomes "Base", but I have no deliberated view. > And, another thing that I thought would be neat would be for there to be > some way for users to specify their own categories so that a "Bob" > category could contain "cygwin, bash, and libtiff" but nothing else. Uhmm, walk first, please :]. IMO the way to do this is to allow merging of metadata from an external file. Such a file could say things like: category Bob cygwin bash libtiff category SSH cygwin bash cygrunsrv ssh and these would merge into the setup.ini listed metadata. Not too hard to do, but I think that having the basic stuff stable is more important now. > 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. Rob