Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Sun, 26 Aug 2001 08:50:19 +0100 From: John Marshall To: cygwin AT cygwin DOT com Cc: prc-tools-devel AT lists DOT sourceforge DOT net Subject: On Cygwin package naming and a setup.exe bug Message-ID: <20010826085019.A1985@kahikatea.pohutukawa.gen.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i http://sources.redhat.com/cygwin/setup.html says Recommended package versioning scheme: use the vendor's version plus a suffix for ports of existing packages (i.e. bash 2.04 becomes 2.04-1, 2.04-2, etc, until bash 2.05 is ported, which would be 2.05-1, etc). For experimental builds, use a YYYYMMDD datestamp version (like bash-20000901.tar.gz). Binary tarballs are "package-version.tar.gz" while source tarballs are "package-version-src.tar.gz". Hi, I'm a vendor. :-) I'm the maintainer of prc-tools, which is a big nasty package encapsulating GCC and a few other tools targetting Palm OS. On our SourceForge downloads page we distribute a source tarball, a few binary RPMs, and a Cygwin binary package. Way back when, producing something our users could install with Cygwin B20.1 was a nightmare involving InstallShield. But I'm very happy these days that I just have to make tarballs that are usable with Cygwin's shiny new setup.exe utility. I've been telling people to download the package from SourceForge into an empty directory (i.e., without any setup.ini lying around) and then use setup.exe's "Install from Local Directory" (which doesn't work anymore: see below), and lately I've been playing with having our own setup.ini file that lists just our package, and telling the users to use our website as a setup.exe "Other URL" mirror, which is even easier for them. However, setup.exe's package naming convention doesn't work especially well when an original vendor like me is producing a Cygwin package. For example, for version 2.1, we (will) have source tarball prc-tools-2.1.tar.gz Linux x86 RPM prc-tools-2.1-1.i386.rpm Cygwin package um... that's why I'm writing... The problem is that the Cygwin package filename doesn't say "cygwin" anywhere. I don't much want to call it "prc-tools-2.1-1.tar.gz" because that's too similar to the source tarball's name and will cause confusion. It would be nice if the convention allowed a filename that was a bit more self-identifying. And because we're the vendor, we don't much want to have a separate "prc-tools-2.1-1-src.tar.gz" because it'll be exactly the same as the main source tarball. So far, I've been calling the binary tarball "prc-tools-2.1-cygwin.tar.gz", and listing the two in our setup.ini as: @ prc-tools version: 2.1 install: contrib/prc-tools/prc-tools-2.1-cygwin.tar.gz 3988138 source: contrib/prc-tools/prc-tools-2.1.tar.gz 284098 This works well in the "Install from Internet" case. However, in the "Install from Local Directory" case (with or without a setup.ini file) do_choose() does a directory scan and finds something whose version it thinks is "2.1-cygwin" and things get confusing (I can go into details if you want -- and in the case of the source package things get very confused indeed). You get the funky version number when you rerun setup.exe, perhaps to uninstall prc-tools, too. Or I could change the version line to "version: 2.1-cygwin" and train the users to believe that when setup.exe says "2.1-cygwin" it really is the same as version "2.1". But that's a bit ugly. For my purposes, it would be nice if parse_filename() treated "-cygwin" as not part of the version, similarly to "-src" and "-patch". I've been playing with this patch: --- choose.cc.orig Fri Aug 17 14:01:22 2001 +++ choose.cc Fri Aug 24 14:40:47 2001 @@ -1280,6 +1280,10 @@ parse_filename (const char *in_fn, filep p = f.pkgtar + (p - fn) + 6; memcpy (p - 6, p, strlen (p)); } + else if ((p -= 1) >= ver && strcasecmp (p, "-cygwin") == 0) + { + *p = '\0'; + } } strcpy (f.ver, *ver ? ver : "0.0"); which makes it treat "package-version-cygwin.tar.gz" just the same as "package-version.tar.gz". This works very nicely, presenting the unadorned "2.1" version number even in the "download just the one file and point setup at it" case. So now I'm wondering whether you folks might think something like that would be an acceptable idea... The source tarball is harder to solve. But I'm not too worried about that: I think the best thing to do will probably be just to not list a source tarball in our setup.ini file, and get the little N/A box instead of a Source? checkbox. Cygwin people who want the source code can just download the source tarball from the downloads web page just like anybody else. So we don't need to do anything special. Using "Install from Local Directory" on a directory containing a single file named prc-tools-2.1-cygwin.tar.gz worked in setup 2.57. But in the current 2.78.2.3 you get "Nothing to Install/Update" because fromcwd.cc has a bug where it creates a Package record for each file it sees, but with a random package name. Later scan2() looks for a record with the right name, doesn't find one, and so doesn't set any existence flags. Then the randomly named package winds up being excluded by set_existence(), and there's nothing left :-(. It's easily fixed: --- fromcwd.cc.orig Sun May 27 08:05:09 2001 +++ fromcwd.cc Fri Aug 24 14:42:31 2001 @@ -87,7 +87,6 @@ static void found_file (char *path, unsigned int fsize) { fileparse f; - char base[_MAX_PATH]; if (!parse_filename (path, f)) return; @@ -104,7 +103,7 @@ found_file (char *path, unsigned int fsi } if (p == NULL) - p = new_package (strdup (base)); + p = new_package (f.pkg); int trust = is_test_version (f.ver) ? TRUST_TEST : TRUST_CURR; (This is against the current CVS HEAD, in which new_package() strdups its name parameter itself.) John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/