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: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <001501c16d6f$a9899c90$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
Cc: <cygwin-apps AT cygwin DOT com>
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF7A48 AT itdomain002 DOT itdomain DOT net DOT au>	<3BE4D4A7	.2070900 AT ece DOT gatech DOT edu> 	<20011104104732 DOT X17306 AT cygbert DOT vinschen DOT de>	<1004867892 DOT 5388 DOT 54 DOT camel AT lifelesswks>  <3BE702C3 DOT 5010008 AT ece DOT gatech DOT edu> <1004999653 DOT 4685 DOT 20 DOT camel AT lifelesswks> <3BE71DF4 DOT 20802 AT ece DOT gatech DOT edu> <3BEFAA8F DOT 4020900 AT ece DOT gatech DOT edu> <3BF17502 DOT 6020902 AT ece DOT gatech DOT edu> <006101c16cd9$8c0e8770$0200a8c0 AT lifelesswks> <010e01c16cef$78c8be90$0200a8c0 AT lifelesswks> <3BF2CA1A DOT 34130B9D AT ece DOT gatech DOT edu> <03b901c16d51$b8f75500$0200a8c0 AT lifelesswks> <3BF2FE81 DOT C586876A AT ece DOT gatech DOT edu>
Subject: Re: patches to vendor source trees - discussion
Date: Thu, 15 Nov 2001 11:51:28 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 15 Nov 2001 00:57:05.0677 (UTC) FILETIME=[71D713D0:01C16D70]


----- Original Message -----
From: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
Cc: <cygwin-apps AT cygwin DOT com>
Sent: Thursday, November 15, 2001 10:30 AM
Subject: Re: patches to vendor source trees - discussion


> Robert Collins wrote:
>
> > > You merely changed the name of the internal tarball slightly.
> >
> > Correct, because it should have been the vendors tarball as is.
>
> Yeah, but didn't "we" decide that src packages should unpack into
> <pkg>-<ver>-<rel>?  I've been making my packages (for the past year or
> more) unpack into <pkg>-<ver> regardless of what <rel> was, and
> distinctly remember concluding that I was "wrong" according to
consensus
> on the list.
...
> I don't have a problem with that, but it is contrary to the
> previously-discussed decision.

That consensus was because of alterations in the source/make
script/cygwin readme etc between each package update, to prevent them
tramping over each other. With those things contained in the patch, only
the patch needs versioning. (IMO).

> > I didn't realise I'd altered the README. Oops. I've been maintaining
> > that what I'm talking about is orthogonal to the package building at
> > this point. However I've updated the script & readme to use the
> > structure I have in the tarball. I've also mailed you another style3
> > tarball... built via 'mktemp-1.3.1-1.sh all'
>
> Sure -- they are orthogonal subjects until you bring a human into the
> process.  Who has to unpack the -src dist, and then build it.  As soon
> as you try to give that human instructions on unpacking/building, you
> create a link between the packaging and building -- thru the README
file
> and the .sh/rules/make/script.

I see the point. My point was that what we have for building already -
your CYGWIN.PATCHES/foo-ver-rel.sh script works well.

>
> The styleX-mktemp-1.3.1*.README and styleX-mktemp-1.3.1*.sh files are
> extracted from the tarballs for easier viewing, but the "dists"
consist
> only of the .tar.bz2 and -src.tar.bz2 files.
>
> Really, Robert, I don't see much difference between style2 and style3:

True.

>
>   style3: unpacks HERE. (e.g. no embedded paths).
>           build script creates -src.tar.bz2 HERE (overwrites
downloaded
> version?)

No, as the downloaded tarball is never saved - setup.exe extracts it
immediately.
i.e. in empty dir /usr/src (as setup.exe currently hardcodes).
run setup.exe download source for foo-2 (foo is the vendor name+version
combined)
you get foo-2.patch and foo.tar.bz2.

And if you do have an existing foo-2-src tarball, then yes the idea is
to replace it, after all you are making a new one deliberately. (or you
would not have passed "all" to the script.)

>           build script creates .tar.bz2 HERE

yes.

> READMEs and build scripts differ only to support these ^^^^
differences;
> otherwise, they are the same.

Yup. The directories and patch location are the only things I've been
harping on about. IMO they are very important.

Rob