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: <3BF5EEC6.4020803@ece.gatech.edu>
Date: Fri, 16 Nov 2001 23:59:50 -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: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
CC: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>, 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> <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> <001501c16d6f$a9899c90$0200a8c0 AT lifelesswks> <3BF3180C DOT 8A99A5E8 AT ece DOT gatech DOT edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Okay, after two days we've gotten one reply, from Kevin Roth (a 
nonmaintainer, I think).  But nothing else.

Are any *current* maintainers going to help us decide here, or am I going 
to have to fly down under for a Robert-v-Chuck arm-wrestle match to settle 
this?

See http://www.neuro.gatech.edu/users/cwilson/cygutils/packaging/

To restate the positions;
  mine: (#1)
    -src tarball contains
       cygwin/SOURCES/<pristine tarball, without renaming or repacking>
       cygwin/SOURCES/<patchfile>
       (possibly other stuff in cygwin/SOURCES/, if necessary)
       cygwin/SPECS/<build script or makefile>
    newly generated tarballs placed in cygwin/RPMS
    newly generated src tarballs placed in cygwin/SRPMS
    since setup will unpack the cygwin-distributed -src tarball under 
/usr/src, all this stuff therefore happens in /usr/source/cygwin/*/
    the build script, when run, unpacks the pristine tarball and renames 
the unpacked directory to be "pkg-ver-rel" instead of whatever the upstream 
developers may have chosen for their source packages (mv tiff-v3.5.5/ 
tiff-3.5.5-2/).  This way, we fit into "the cygwin way" but don't have to 
repack the "pristine" tarballs at all.
   (Alternatively, we don't *HAVE* to do this.  We can just use whatever 
dirname the upstream folks put in their pristine tarball.  It's all 
controlled by the script in SPECS/)

Good points:  more "RPM" like.  Also, the build script is right there -- no 
need to unpack & patch first; the build script will do that for you. 
Therefore, this is more automated.

Bad points: assumes a cygwin/*/ structure.  (Not *necessarily* 
/usr/src/cygwin/*/ -- it could be ~/cygwin/*/)

---------------------------------------------------
   Robert's: (#3)
     -src tarball contains
        <pristine tarball, without renaming or repacking>
        <patch>
      since setup unpacks these under /usr/src, these files end up right 
there in /usr/src.
      newly generated tarballs are placed *right here* (in /usr/src)
      ditto newly generated -src tarballs
      Currently, one must manually unpack the pristine tarball, and apply 
the patch.  (Later, perhaps setup can do this for us).  Then, the build 
script is created inside the unpacked source directory.

Good points:  self contained. The build script need not assume anything 
about the "surrounding' directory structure.  once the user unpacks and 
patches, <srctop>/CYGWIN-PATCHES/buildscript will do all the work, and 
generates the new tarballs in <srctop>/..

Bad points: User must manually unpack and patch (or setup must do it). 
IMO, having the build script inside the source tree is awkward.  Also, 
there seems to be little provision for additional patches or archives if 
the "pristine" src archive + 1patch isn't enough to properly handle the 
port (cf. /usr/doc/Cygwin/ncurses-5.2.README)

---------------------------------------------------
   Worst of both worlds: (#2)
     -src tarball contains
       cygwin/SOURCES/<pristine tarball, repacked, renamed>
         renamed so that the tarball follows some agreed-upon
           standard name (foo-ver-origsrc.tar.bz2 ?)
         repacked so that it will unpack into an agreed-upon
           standard directory (foo-ver-rel/ ?  foo-ver/ ?)
           instead of whatever random thing the upstream folks
           picked (jpeg6b?  tiff-v3.5.5? Ugh).
     apply the patch, and then the build script is created within
the unpacked source directory.  It is assumed that the user (or setup) will 
unpack the pristine source into cygwin/BUILD.  That script will 
(eventually) generate the new tarball in cygwin/RPMS, and the new -src 
tarball in cygwin/SRPMS.

good points: Closer to the RPMish structure. (?)

Bad points: repacking, renaming the "pristine" tarball.  Also, assumes a 
lot about *where* the end user will manually unpack -- unless setup does 
this for us. Also the single src archive + 1 patch only problem.

---------------------------------------------------

--Chuck