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: <3BE71DF4.20802@ece.gatech.edu>
Date: Mon, 05 Nov 2001 18:17:08 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: Corinna Vinschen <cygwin-apps AT cygwin DOT com>
Subject: Re: patches to vendor source trees - discussion
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>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Robert Collins wrote:


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


Oh, okay.

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


Yeah, for my initial version, you are correct.  I had %SOURCES/foo/, 
%DOCS/foo/, %INST/foo/, etc.  Now I've scrapped all that.  Just %SOURCES. 
%SPECS. etc.


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


Well, I guess I can live with it.  The only remaining problem is one I 
haven't yet mentioned.  I was hoping it wouldn't come up. Binary data (and 
related: multiple source archives)

For instance, the libtiff -src package contains
(a)  CYGWIN-PATCHES/libtiff-lzw-compression-kit.tar.gz
(b)  CYGWIN-PATCHES/tif_rpt_3.4b33.tar.gz
   as well as the expected
(c)  CYGWIN-PATCHES/tiff-3.5.6.README
(d)  CYGWIN-PATCHES/tiff-3.5.6beta-2.patch

There's no way that (d) -- or any other .patch -- can be used to create (a) 
or (b).  Now, those files don't HAVE to be distributed as .tar.gz's -- they 
could just be unpacked (by me as the maintainer) under CYGWIN-PATCHES, and 
then the .patch file could create those *unpackaged* files directly.  So 
*perhaps* that's a non-issue.

The other problem that may crop up, but hasn't yet: *TRUE* binary data. 
for instance (using libtiff again), in order to get 'make test' to work, my 
README says "go download ftp://ftp.onshore.com/pub/libtiff/v3.4pics.tar.gz" 
and unpack it within your src directory."  Note that it contains a bunch of 
.tiff files -- binary data.  Note also that it's no longer available from 
ftp.onshore.com, you now have to go to ftp.remotesensing.org, but using 
ACTIVE mode ftp only...quite a barrier.  Files moving around on the web, 
restrictions on download protocols so that you can't be behind a firewall. 
  Sure would be nice if we just included this in our -src tarball...

What if I had wanted to include that within the original source archive?  I 
can't include it as a .tar.gz file --- but since it *contains* binary data, 
I (as the maintainer) can't unpack it within MY src dir and THEN generate 
the patch.  Patch will barf.

What this really requires -- if we want to allow it -- is to have *TWO* 
primary source archives within the main -src one;
   SOURCES/tiff-v3.5.6-beta.tar.gz
     (this is the official tiff archvie from www.libtiff.org)
   SOURCES/v3.4pic.tar.gz
     (also a primary archive)
and then the .spec (.sh, .rule) file can handle the appropriate unpacking 
processes.

(note that the official libtiff tarball doesn't follow our naming scheme -- 
e.g. the version number begins with 'v'.  Also, the secondary source 
tarball doesn't have a name that is obviously related to tiff.  That's the 
reason I pushed for subdirs under SOURCES -- to categorize things that 
aren't obviously related but should be.  OTOH, *if* setup gains the ability 
-- later -- to record the few files that are actually unpacked from the 
cygwinish -src tarball, then they can be easily uninstalled without needing 
a special SOURCES/tiff/ subdir.)

These are some of the reasons why, for all of its obvious failings, I 
believe the rpm format has many advantages over other autobuild systems. 
It may be ugly, but it sure is flexible.  'Course, I'm beating a deceased 
equine since Cygnus == Red Hat...

--Chuck