This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [ITP] libungif-4.1.0-2

> -----Original Message-----
> From: 
> [] On Behalf Of Lapo Luchini
> Sent: Tuesday, 16 July 2002 8:58 PM
> To: Charles Wilson
> Cc:;
> Subject: Re: [ITP] libungif-4.1.0-2
> > 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".
> Just had an idea: what about creating a new pass in the script called 
> "automatic" that is intedned to contain all the "automatic task" to 
> patch the source, followed by normal patching?
> This pass would be void normally, but in the cases where it 
> is needed it 
> could contain the relibtoolizing and like things, this would 
> be applied 
> also to "pristine source" in mkpatch, so that the actual patch only 
> contains the differences between the "automatically reapplicable 
> patches" obtaining in most of the cases a patch that is much smaller.
> (unless you change autotools version in between, of course 
> -_-, but its 
> not that smart to change a software in the middle of a packaging)

Lapo, this is bad.

A large patch means that the user does not need the autotools installed,
because the autotool generated files have their changes in the patch.
Secondly, what if the needed version of the autotools isn't available to
them, and newer versions have trouble?

What is the issue with the patch size anyway?
Even a 900K patch will shrink massively when bz2'd, and the user doesn't
have to look at the content of the patch.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]