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
Message-ID: <02a301c17084$9b178b50$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>, <cygwin-apps AT cygwin DOT com>
References: <3BF8385F DOT 8010606 AT ece DOT gatech DOT edu>
Subject: Re: -src package standard: proposal #5 and #5a
Date: Mon, 19 Nov 2001 09:58:57 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
To: <cygwin-apps AT cygwin DOT com>
Sent: Monday, November 19, 2001 9:38 AM
Subject: -src package standard: proposal #5 and #5a


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

This is false. That "one patch" just creates the CYGWIN-PATCHES, which
can thus contain as many ready to apply patches as you need. Which
package is it - ncurses? - that this causes you grief with and I'll show
you what I mean.

b and c are not part of my proposal, never have been.

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

Show me the packages. I'll do the hard work.

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

Ok, this sounds reasonable... how about this script though.
====
#!/bin.sh
echo "unpack the source archive, apply the patch, and then optionally"
echo "build the package for you using the script found in "
echo "<srcdir>/CYGWIN-PATCHES/ to build this package."
echo "Call this script like \"cygbuild packagenameandversion\""
echo "add --build to cause the package to be built"
...
<not real script>
dirname = sed rule on $1
packagever = sed rule on $1 to remove cygwin version
if [test -d $dirname ]; then
  mv dirname dirname.old
fi
tar xjf ${packagever}-src.tar.(bz2|gz)
cd dirname
patch -p1 ../$1.patch
cd ..
if (--build was passed)
  ${dirname}/CYGWIN-PATCHES/${1}.sh all
fi
===

That could be put in /bin by a package - call it cyghelper - and called
something like cygbuild, and is global for all packages. And setup.exe
doesn't need to extract the inner source, it can just look for cygbuild
and if it's there invoke it appropriately (ie without --build).

> Now, if setup.exe is going to (eventually) unpack and patch, why
include

I'm lazy. I actually want to get setup calling out to cygwin programs
that can do that - ie rpm --magic-parameters or apt-get source. Minor
stuff along the way seems a good compromise to get things moving (to
me).

> 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."

Thats trivial Chuck. Shar the tarball to make it 7 bit safe, put it in
CYGWIN-PATCHES and then just make your patch. have the build script
apply that patch AS IT GOES.

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

Again, I see no point in getting this much stuff into setup. Setup can
call out to programs to do this. Folk wanted a gui to get source, the've
got one.

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

Again, not needed. point me at a problem package, and I'll set it up in
src + 1 patch format.

Rob