[ITP] libungif-4.1.0-2

[Charles Wilson]

Lapo Luchini wrote:

>> You should either
>>   1) change mkpatch() to only create a diff between your populated 
>> libungif-4.1.0\CYGWIN-PATCHES directory and an empty 
>> libungif-4.1.0-orig\CYGWIN-PATCHES, and keep the "aclocal && 
>> libtoolize --force" command in conf(), or
>>   2) Lapo runs "aclocal && libtoolize --force" by hand, and then uses 
>> mkpatch to create a gigantic patch that includes not only 
>> libungif-4.1.0\CYGWIN-PATCHES, but also the libtoolization bits. 
>> "aclocal && libtoolize --force" is removed from conf().
>>
>> Also, it should probably be "aclocal && libtoolize --force --copy && 
>> automake --gnu --copy --add-missing --force-missing && autoconf" but 
>> that's just me.
> 
> 
> Or maybe moving spkg before conf? Is it too "dirty" to let conf actually 
> change the dir content?


No, you're just missing the point.  Suppose I have a package that DOES 
need a few changes to .c files in order to compile.  Now, of course, I 
don't know what those changes are BEFORE I begin working on the package.

So, I relibtoolize and re-automake etc.  I configure.  I make -- and it 
fails in foo.c.  I fix foo.c.  I make again, and it fails in bar.h.  I 
fix bar.h...etc.

Now, I'd like to make the distribution -src package...

mkpatch() creates a patch that contains all of the changes that I have 
made -- including the re-autotoolization.

End user can apply the patch -- even without having the autotools -- and 
'configure; make' and it should 'just work'.  OTOH, the patch is 
gigantically huge.  So, there's a compromise: I can edit the gigantic 
page, removing all of the autotoolization stuff, leaving only my changes 
to foo.c, bar.h, and everything that is in CYGIWN-PATCHES/.  But that's 
hard to automate.

The decision on how to handle this is, of course, a maintainer decision. 
   I have done all of the following in various packages, because each 
package is different:

   1) just ship the gigantic patch
It's automatic, I don't have to worry about it; the end users don't need 
the autotools.  The buildscript doesn't call aclocal or any other 
autotools.  But the patch is big.

   2) IF and ONLY IF there are no changes to "real" files (foo.c, bar.h, 
confiugre.in) -- the only changes are in CYGWIN-PATCHES/ and 
re-autotooliation -- then I can "fake" the patch.  In mkpatch:
    mkdir -p ${topdir}/foo-VER-orig/CYGWIN-PATCHES
    cd ${topdir}
    diff -urN foo-VER/CYGWIN-PATCHES  foo-VER-orig/CYGWIN-PATCHES > patch

Thus, I can be sure that 'patch' contains only the changes in CYGWIN-PATCHES 

and none of the autotoolization.  The buildscript calls the autotools, the

end user must have the autotools installed.  The patch is small. 
Downside: if I ever need to modify a "real" file (foo.c, bar.h) then I 
must change the build procedure, which is a PITA.

   3) Suppose I need to change some "source" files to get the -deve- 
autotools to work properly. This is the most difficult option.  I can 
create a "pre-autotoolization" patch, which includes my changes to 
foo.c, configure.in, Makefile.am, etc.  I generate that patch by hand, 
*before*running the autotools.  'mkpatch()' becomes
    cp <patchfile> ${sinst}/
    cp <orig taball> ${sinst}/
    cp <buildscript> ${sinst}/
    echo "I didn't recreate the patch; any changes you made"
    echo "to the sources will be lost"
The buildscript calls the autotools.  The end user must have them 
installed.  The patch is small -- but if it ever needs changing, I must 
recreate it manually.


> Package with spkg moved just before "conf" and after "prep" (it seemed a 
> bit overkill to call it -3 for just this small change):
> http://www.lapo.it/tmp/libungif-4.1.0-2.tar.bz2
> http://www.lapo.it/tmp/libungif-4.1.0-2-src.tar.bz2


This is basically version #3 -- instead of simply copying the patch, 
you're recreating it: but you are guaranteed that the "new" patch will 
be identical to the old one, since "spkg" is called immediately after 
"prep".

--Chuck