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: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Message-ID: <3BF83F7D.5000005@ece.gatech.edu> Date: Sun, 18 Nov 2001 18:08:45 -0500 From: Charles Wilson 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 CC: cygwin-apps AT cygwin DOT com Subject: Re: -src package standard: proposal #5 and #5a References: <3BF8385F DOT 8010606 AT ece DOT gatech DOT edu> <02a301c17084$9b178b50$0200a8c0 AT lifelesswks> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert Collins wrote: > > 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. !!!! I know. That's my point. Your proposal CANNOT handle certain problems. Sure, you *could* have .patch create another patch (blech -- I HATE meta-patches...) but you CAN'T create a binary file using text tools, like patch.exe -- that is, until Corinna made sharutils an official package yesterday. (Blech again.) > Show me the packages. I'll do the hard work. Okay, I've got to run to a concert, but I'll show you some problematic packages when I get back. Note: haven't looked closely at your script below, will do later. Observation: external proggie like cygbuild has only been obliquely mentioned prior to this point; are you making it a central feature of your proposal now? > 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 "/CYGWIN-PATCHES/ to build this package." > echo "Call this script like \"cygbuild packagenameandversion\"" > echo "add --build to cause the package to be built" > ... > > 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). Again, I'll address this script + cygbuild later... > >>Now, if setup.exe is going to (eventually) unpack and patch, why >> > include (um, this ^^^ was a rhetorical question...) > 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). > > 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. Oh god. Not shar ... > 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. > > Again, not needed. point me at a problem package, and I'll set it up in > src + 1 patch format. Okay, I'll take you up on that, when I get back... Gotta run. --Chuck