Re: On Cygwin package naming and a setup.exe bug

[Christopher Faylor <cgf@redhat.com>]

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/