-src package standard: proposal #5 and #5a

[Charles Wilson]

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. <g>)

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 "<srcdir>/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 
<srcdir>/CYGWIN-PATCHES/<buildscript> 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 <srctop>/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 <filename???>".  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 
<filename>" or "patch -p0 <patchname>" -- 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.