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 13:46:05 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: On Cygwin package naming and a setup.exe bug Message-ID: <20010826134605.D3967@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20010826085019 DOT A1985 AT kahikatea DOT pohutukawa DOT gen DOT nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010826085019.A1985@kahikatea.pohutukawa.gen.nz> User-Agent: Mutt/1.3.21i On Sun, Aug 26, 2001 at 08:50:19AM +0100, John Marshall wrote: >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. And a cygwin source package, hopefully, if you want to be in compliance with the GPL. If you are providing cygwin1.dll, you must provide sources for cygwin1.dll. If you are providing any other binaries that use cygwin1.dll you most provide sources for them, also. >However, setup.exe's package naming convention doesn't work especially >well when an original vendor like me is producing a Cygwin package. Not surprising since this isn't a goal for setup.exe. It's really only intended to install cygwin packages. >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. Sounds like a separate subdirectory would solve the problem. >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. I.e., the version mechanism is doing what it was designed to do. If you are going to put a cygwin after the numeric version, it will interpret the cygwin as part of the version. >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. Why not just put the cygwin- first rather than last? Or use a subdirectory? >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... I'd have to get a ruling from other developers to see if this screws up anything else. I've got mixed feelings about putting concessions for other packages in setup. It isn't really supposed to be a general purpose installation tool. >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.) Thanks for the patch. I've applied it to CVS. cgf -- 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/