Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Message-ID: <3BF8385F.8010606@ece.gatech.edu> Date: Sun, 18 Nov 2001 17:38:23 -0500 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: cygwin-apps AT cygwin DOT com Subject: -src package standard: proposal #5 and #5a Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The scheme I proposed had two main points: 1) I like having the build script outside of the build/src tree (like rpm's .spec files). This allows more automation and flexibility from the build script -- otherwise, you're stuck with a) one pristine src file + one patch -- works okay if life is simple. Even setup.exe can be modified to handle this (which would be nice). b) one pristine src file + multiple patches that must be installed prior to configury. (ie. a "cygwin" patch and a "standard" patch -- like lossless jpeg). Setup can't be expected to handle this for you, AND there are no instructions describing what the user is supposed to do (until after the user manually unpacks and applies the first patch...see below for why this in itself is problematic) c) pristine src files + multiple patches, where some patches are applied before configury and some are applied after (such as "incomplete" dll ports, like the current readline and ncurses packages.) No way setup.exe can handle this, AND again there are no instructions. Unless the instructions are in /usr/doc/cygwin/foo-1.2.README, in which case the user has to download and install the binary foo before trying to build it from src. Blech. 2) I like separating things into different directories, and the rpm dir structure is as good as any. However, I can live without #2. However, Corinna came out "strongly" for something RPMish -- and Chris has made no comments so far. (I think he's practicing "hands off management" :-) Let the peons fight it out, and then come out in favor of the winning version...it was "obviously" the best proposal. ) So, my compromise proposal below has no rpm-derived CAPITAL directories. No cygwin/SOURCES. no cygwin/SPECS. etc. I can even (mostly) live without #1. I'm more interested in getting a -src standard *specified* than in actually winning this argument. However, with Robert's #3 proposal it will be *IMPOSSIBLE* to release some of my current packages in that form. It just will *NOT* work in an automated fashion -- they are (b) and (c) type packages, not (a) type packages. I want to release mktemp, misc, readline-4.2a, and prepare "new" packaged versions of autoconf-2.13/2.52/scripts, automake-1.4p5/1.5/scripts for Corinna. So, I propose the following compromise (almost identical to Robert's #3, with one addition): Let's call this proposal #5 (since Gareth took the #4 slot for his proposal): just like Robert's #3, BUT -src also contains (in addition to pristine src tarball and a patch) "foo-ver-rel.sh" which is unpacked at the top level. E.g. if foo-1.2-3-src.tar.bz2 is unpacked into /usr/src, you'd end up with: /usr/src/foo-1.2.tar.bz2 /usr/src/foo-1.2-3.patch /usr/src/foo-1.2-3.sh tar tvjf foo-1.2-3-src.tar.bz2 would show: foo-1.2.tar.bz2 foo-1.2-3.patch foo-1.2-3.sh If "foo" is a simple package (e.g. type (a) above -- only needs the one source file and the one patch, no tricky stuff) then foo-1.2-3.sh is the following: ------ #!/bin/sh # SETUP: unpack patch echo "unpack the source archive, apply the patch, and then use" echo "the documentation and build scripts/makefiles found in" echo "/CYGWIN-PATCHES/ to build this package. If you are" echo "lucky, setup.exe has already unpacked and patched for you." ------ otherwise, the functionality of foo-1.2-3.sh is whatever the maintainer needs it to be in order to automate the build -- and may even supplant the /CYGWIN-PATCHES/ if desired. However, it MUST contain a --help option (the simple version doesn't need a help *option* because 'foo-1.2-3.sh --help' will just print the message above anyway.) (Okay, so if "simple" packages are going to contain the .sh anyway -- why can't it just do the unpack and patch, and *then* instruct the user to go look at /CYGWIN-PATCHES/ ? Because, it would then need to change to track releases -- "tar xv[z|j]f foo-???[tar.gz|.tar.bz2|.tgz|tbz]" and "patch -p0 ". The simple.sh should NEVER need to change. setup.exe already knows what the filename of the inner archive is, and the file magic code that is in CVS can figure out how to unpack it, and setup.exe already knows the filename of the patch. Bascically, I want impose the ABSOLUTE MINIMUM inconvenience on maintainers of simple packages -- and a cookbook "make foo-ver-rel.sh exactly like this and never ever change it" is as minimum as you can get, while still allowing the flexibility needed for more complex packages... Now, if setup.exe is going to (eventually) unpack and patch, why include the .sh at all -- even for complex packages? If setup.exe is modified to automagically unpack and patch, then complex (exp. type (b)) packages will break. Typically, you need to apply the "standard" patch first, before the "cygwin" patch -- otherwise, how can you automate rebuilding the cygwin patch itself? What if the "patch" is actually "okay, there's this secondary tarball which contains some binary files -- replacement .png icons or something (I'm thinking XEmacs here) -- so you need to untar the secondary archive on top of the primary one, etc." That's why the simple foo-1.2-3.sh has the magic incantation: "# SETUP: unpack patch". If this setup.exe sees this magic, it unpacks the (lone) inner archive & patches it (using the lone patch). (No need to say "unpack " or "patch -p0 " -- again because, for simple packages, setup can easily figure this out). If setup doesn't see the magic incantation, it just unpacks -src and stops -- leaving it to the (non-simple) foo-1.2-3.sh script to do the work. Is this an acceptable compromise? --Chuck P.S. proposal #5a: simple packages: IDENTICAL to Robert's #3 (no foo-1.2-3.sh). Setup (eventually) will be able to unpack the inner archive and patch automatically. complex packages: as above, with a foo-1.2-3.sh. Setup does not unpack the inner archive. Existence/non-existence of foo-1.2-3.sh is the "trigger" that informs setup.exe whether or not to unpack the inner archive.