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
Subject: Re: patches to vendor source trees - discussion
From: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
To: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
Cc: Corinna Vinschen <cygwin-apps AT cygwin DOT com>
In-Reply-To: <3BE702C3.5010008@ece.gatech.edu>
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>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.15 (Preview Release)
Date: 06 Nov 2001 09:34:11 +1100
Message-Id: <1004999653.4685.20.camel@lifelesswks>
Mime-Version: 1.0
X-OriginalArrivalTime: 05 Nov 2001 22:40:19.0333 (UTC) FILETIME=[D8C29B50:01C1664A]

On Tue, 2001-11-06 at 08:21, Charles Wilson wrote:
> Robert Collins wrote:
> 
> > I've been trying to keep well away from the rpm vs deb issue. I've not
> > been suggesting that setup be altered *at all*.
> 
> I don't think setup need be altered.  I think Corinna's suggesting that we 
> adopt the rpm directory tree for the internal layout of our -src tarballs.

I must have misread Corinna's mail - oops.
 
>  
> > And yes, I think that cygwin's setup.exe should be quite limited in
> > scope for installation of source.
> 
> 
> Sounds like Corinna's advocating what is essentially a compromise between 
> Robert's proposal and mine:
> 
> 1) use a multiple directory heirarchy.  Not as many as I wanted, but sticks 
> with the RPM standard set.
> %/BUILD
> %/RPMS
> %/SOURCES
> %/SPECS
> %/SRPMS.
> where % = /usr/src/cygwin/
> 
> 2) single patch file (for new style -src dists)
> 
> except that there are a few twists that don't originate from either Robert 
> or my proposal:
> 
> I assume that, in Corinna's scheme, RPMS and SRPMS will NOT, at present, 
> contain *actual* rpms nor srpms.  Mebbe we can use those dirs -- on an 
> interim basis -- as the place where newly built .tar.bz2's and 
> -src.tar.bz2's are stored.  But primarily they're just placeholders right now.
> 
> Corinna is not suggesting any change to the internal format of the -src 
> tarball.  It's just a tarball, unpacks into foo-ver-rel/*.  Period.  Except 
> that setup no longer unpacks it.

..or maybe I didn't misread. This sounds like a setup.exe change to me
:}.
For the record, apt doesn't unpack it either (be default). I wasn't
suggesting we change this though.
 
> If the package maintainer desires, he may also choose (for new versions/new 
> packages) to :
>    a) take the pristine tarball and rename it according to current 
> conventions (*)
>    b) place a similarly named .diff file *on the cygwin mirror*
>    c) place a similarly named .spec file *on the cygiwn mirror*
> 
> If these extra files exist, setup will download them into %/SPECS and 
> %/SOURCES.  This may require changes to cgf's upset script, additions to 
> the setup.hint and setup.ini grammar, as well as mods to setup.exe itself.

Yup.
 
> It is unclear whether the .spec file must be a true rpm-style spec file, or 
> just a file that ends in .spec (might be a debian-like rules file?  or a 
> cwilson-like build script?)
...
 
> --------------------
> 
> I don't like this, for several reasons:
> 
> (1) requires too much mucking around with setup, upset, setup.ini, and 
> setup.hint.

Yes.

> (2) One of the BIG advantages of rpm/deb is EVERYTHING goes in one archive. 
>   -src.deb or .srpm.  Stuff won't get lost, or accidentally desynchronized.
> (3) I think BOTH my proposal and Robert's proposal are simpler, from the 
> tools side.  Neither really seems to require ANY changes to setup.ini, 
> upset, setup.hint. Robert's does seem to require changes to setup.exe.
>    Mine:
>      pkg maintainers, make your -src package look like this:
>        (the -src.tar.bz2 will contain a pristine source tarball
>        itself, which is merely placed in %/SRC/ (because of the
>        paths in the downloaded -src.tar.bz2 file).  The secondary
>        internal pristine tarball is NOT further unpacked)
>      setup.exe, download the -src archive and unpack into /usr/src/cygwin/

k. thats easy.

>    Robert's:
>      pkg maintainers, make your -src package look like this:
>        (the -src.tar.bz2 will contain a pristine source tarball
>        itself, which is placed in % and IS further unpacked)

This could be just like yours IMO. I'd prefer that really. (-src.tar.bz2
contains a inner tarball that is *not* unpacked + the global patch.

>      setup.exe, download the -src archive and unpack into % (usr/src ?)
>        That will create %/fooVER.tar.bz2 and %/fooVER.dif  Unpack that
>        secondary tarball, and then apply the fooVER.dif patch.  This
>        will create a %/fooVER/debian directory with a rules file, etc

> My proposal (revised)
>    Use the standard RPM tree (SOURCES, BUILD, SPEC, RPMS, SRPMS)
>    -src is a tarball which contains
>      SOURCES/foo-VER-REL-orig.tar.bz2
>      SOURCES/foo-VER-REL.diff (creates the cgywin README)
>      SOURCES/foo-VER-REL-X.diff (if necessary)
>      SPECS/foo-VER-REL.*
>        .spec or .sh or .rule or whatever.
>    setup unpacks this into /usr/src/cygwin.
>    the end.  Nothing else is specified yet.

I still don't like %SOURCES + %SPECS. IMO it's _not_ a deep vs wide
thing.

deep might be
%foo/SPECS
%foo/DOCS
%foo/SOURCES

and wide is what I've been talking about.

What you've ben talking about AFAICT is wide+deep.
%SOURCES
%SPECS
%DOCS
are wide,
and then undersources, you go deep.
 
> In other words, if -src.tar.bz2 contains SPEC/*.rule, then follow the 
> debian rules; ONE diff file which creates the debian-style rules file and 
> whatnot.  Robert's '%' == /usr/src/cgywin/SOURCES.
> 
> Yeah, it's complicated, but no more so than the current system of ' 
> download, unpack, and then try to follow the (nonexistant?) build 
> instructions in /usr/doc/Cygwin/foo.README.

I think that there is more being read into what I've suggested than I
intended.

let me rephrase. (incorporating your idea of wrapped source tarballs).

setup.exe code changes. NONE.
maintainer patch management and build process changes. NONE. 
-src tarball creation changes:
1) the uploaded tarball changes. It becomes a tarball with two files in
it.
a) pristine vendor source.
b) a single patch - that makes the pristine source look like *THE
CURRENT SRC TARBALL LOOKS LIKE*

So Chuck, I still dont' see - HOW this conflicts with your multiple
patch approach. The user sees the same thing once they patch the source
dir.

Rob