-src package standard: proposal #5 and #5a
Mon Nov 12 10:06:00 GMT 2001
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
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:
tar tvjf foo-1.2-3-src.tar.bz2 would show:
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
# 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?
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.
More information about the Cygwin-apps