This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: [ITP] libgcrypt-1.2.0-2
- From: "Gerrit P. Haase" <gerrit at familiehaase dot de>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 1 Oct 2004 15:39:07 +0200
- Subject: Re: [ITP] libgcrypt-1.2.0-2
- Organization: Esse keine toten Tiere
- References: <415C4198.6030703@scytek.de> <415C577F.5000809@x-ray.at><51722749439.20041001123047@familiehaase.de> <415D58F1.7030604@x-ray.at>
- Reply-to: "Gerrit P. Haase" <gerrit at familiehaase dot de>
Hi Reini,
>>>>I'd rather run ./autogen.sh style scripts in the conf step.
>>
>> That would give the same patch size (usually it runs also aclocal,
>> libtoolize, autoconf, automake).
> no, do it in the .sh script. That keeps the patch to the bare and
> readable minimum,
I cannot confirm that it reduces the patch sizes. It will always be
huge, even if you use automake-1.8 where the upstream package includes
automak-1.79 generated files.
> and you only have to persuade the maintainers upstream to use
> the newer 1.5 autotools. (just for our dll's, but what the heck.)
> with the monster patch (new libtool, .in files, ...) they might get
> frightened.
I don't submit those patches upstream, the only patches I submit
upstream are against Makefile.am and configure.in files and of course
source fixes.
> And our src dependencies in the README must list the -devel autotool 1.5
> requirements of course, otherwise it will fail, and your explicit patch
> must be used.
Yes, that is the reason why I include the patch, otherwise, Iwe could
add lines like: /usr/autotool/devel/bin/autoreconf -fiv to the script,
but then it will fail as soon as newer autotool version are avaiable or
the user has older versions installed. Additionally I need to use a
pacthed libtool which is also included with the patch, if I would not
patch libtool I would have to patch at least ten Makefile.am of GLib &
Co. and probably other packages too.
Gerrit
--
=^..^=