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: Tue, 28 Aug 2001 14:00:25 +0100 From: John Marshall To: cygwin AT cygwin DOT com Subject: Re: On Cygwin package naming and a setup.exe bug Message-ID: <20010828140025.A1172@kahikatea.pohutukawa.gen.nz> References: <20010826085019 DOT A1985 AT kahikatea DOT pohutukawa DOT gen DOT nz> <20010826134605 DOT D3967 AT redhat DOT com> <3B8A2372 DOT 5149A050 AT etr-usa DOT com> <20010827133917 DOT B18761 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010827133917.B18761@redhat.com>; from cgf@redhat.com on Mon, Aug 27, 2001 at 01:39:17PM -0400 Christopher Faylor wrote: >>> Not surprising since this isn't a goal for setup.exe. It's really only >>> intended to install cygwin packages. Okay, but the file I'm talking about *is* a Cygwin package, at least in the sense in which I was naively using the words. I was using "Cygwin package" to mean "package using the Cygwin environment and installable by Cygwin's setup.exe", i.e., "a file, like grep-2.4.2-1.tar.gz, which is a [bg]zipped tarball containing executables and such in a /usr/bin, /etc etc sort of directory hierarchy as described in http://cygwin.com/ml/cygwin-apps/2000-11/msg00055.html." > The PRC-Tools are not distributed from the cygwin web site. They are > not an official cygwin package. Ah, so setup.exe is only intended to install *official* Cygwin packages, it's not supposed to be a general installation tool. That's fair enough. But it seems a shame, because it's so close to being that general tool. I'm a vendor with a reasonably non-tiny package who supplies binary packages for the convenience of the users. It's a collection of Unix applications, so of course on Windows we build it as Cygwin applications. On Linux, building an RPM is easy, and the users have tools to install such beasts, so it's convenient to build the binary package as an RPM. On Solaris, building a pkgadd package is not too horrifying, and the users have tools to install such beasts, so it's convenient to build the binary package as a pkgadd package. On Cygwin, building a setup.exe-tarball is easy, and the users have a tool to install such beasts, so it would be convenient to build the binary package as a setup.exe-tarball. In short, I want to think of setup.exe the same way as Bernard Dautrevaux: as *the* package management tool for Cygwin. (That's certainly what it looks like it is when you use it!) I understand that this was not one of the original design goals. But it seems to me that it would not be difficult and would be useful for Cygwin users (and also for package distributors like me), so I want to open a discussion on it. I'm surprised that this seems to be a new thing. I would have thought that there would be lots of people wanting to do what I want to do (distribute a binary package that runs in a Cygwin environment, but which is not fundamental enough to be worth adding to the list of "official Cygwin packages" hosted on the Cygwin web site). People including me have suggested various workarounds that I could use. Workarounds involving subdirectories and/or symlinks on the server are in fact irrelevant, so I'm sorry I didn't adequately explain the problem I'm really trying to address. I can use symlinks or whatever to set up whatever complicated stucture I like, but what I'm really trying to do is avoid confusing the users. I can use various tricks in my setup.ini file with the existing setup.exe program to conform to the naming convention and make everything work in the "Install from Internet" case. That's fine. But, in a perfect world, it would be good if the download-manually-and-"Install from Local Directory" case worked well too, because I suspect that's what more knowledgeable users will want to do. Imagine a perhaps not enormously knowledgeable user who goes to http://sourceforge.net/project/showfiles.php?group_id=4429 and downloads a few files, perhaps a source tarball and a binary package, into some temporary directory. Regardless of whatever subdirectory or symlink structure they might have had on the server, on this user's local drive they are just a bunch of files identified by their names. Later they come to look at and/or install these files. By now, they've forgotten all about them and the only information they have to go on is the filenames. If the Cygwin binary package they've downloaded is called prc-tools-2.1-1.tar.gz, people *will* get confused about the difference between prc-tools-2.1.tar.gz and prc-tools-2.1-1.tar.gz, and they'll send me email about it. I'd like to be able to avoid generating that confusion. I can use various workarounds to do that more or less successfully. As I suggested, I can call the file prc-tools-2.1-cygwin.tar.gz, with the side-effect that the version is 2.1-cygwin instead of 2.1. As Charles suggested, I can call the file prc-tools-cygwin-2.1.tar.gz, with the side-effect that the package name will be listed in the UI as prc-tools-cygwin instead of prc-tools. This is workable, but not aesthetically satisfying. I *will* get email from moronic users asking why "prc-tools 2.1" is listed as "2.1-cygwin" or "prc-tools-cygwin". If I provide two source tarballs with different names -- prc-tools-2.1.tar.gz and prc-tools-2.1-src.tar.gz -- as Charles suggested, I *will* get email from morons asking what the difference between them is. In a perfect world, the Cygwin package naming convention would be compatible with avoiding all this confusion. The situation is workable at the moment, and I could just go away and use one of these workarounds and live in an imperfect world (and just ignore all the moronic email I'm going to get). In fact, considering the flame war that my not especially well explained but well-intentioned posting seems to have produced, I might do just that. :-) But this is free software, and I do like to strive for aesthetics and a perfect world. It is my opinion that setup.exe can be extended in this way with very little maintenance burden, so if there's interest in making life easier for users and developers of non-standard packages like this running on Cygwin, I do think it's worth discussing and I hope I've motivated the issue better this time. I've got another IMHO even better suggestion, which I think poses less risk to the name parsing, which I'll present if there's interest. But this email is already far too long and boring, and I'm out of time right now... As for the side issue of GPL compliance etc, I don't want to waste your time by addressing it here. I thank Christopher for his advisory notes, but I assure you that I do understand the issues and we do fulfill all our obligations under the GPL. Of course, I don't expect anyone to believe that just because I said so :-), but I do expect to be given the benefit of the doubt. If anyone wants to dispute my assurance above, they really ought to check the facts at http://prc-tools.sourceforge.net/ first. 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/