This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

On Cygwin package naming and a setup.exe bug


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]