[Reproducible-builds] [PATCH] Upstreaming a large amount of patches

[Holger Levsen]

Hi,

On Wed, Mar 23, 2016 at 12:33:04AM +0100, Reiner Herrmann wrote:
> > [https://lists.gnu.org/archive/html/info-gnu/2010-07/msg00023.html]
> > 
> > " * WARNING: Future backward-incompatibility!
> > "   Wildcards are not documented as returning sorted values, but up to and
> > "   including this release the results have been sorted and some makefiles are
> > "   apparently depending on that.  In the next release of GNU make, for
> > "   performance reasons, we may remove that sorting.  If your makefiles
> > "   require sorted results from wildcard expansions, use the $(sort ...)
> > "   function to request it explicitly.
> > 
> > (But the change actually went into 3.82, not a future release; as the
> > ChangeLog in the source says:
> > 
> > " 2010-08-13  Paul Smith  <psmith at gnu.org>
> > "
> > "         * NEWS: Accidentally forgot to back out the sorted wildcard
> > "         enhancement in 3.82, so update NEWS.
> > 
> > -- after it had already been posted to the mailing list as a threat of
> > *future* change...)
> > 
> > "for performance reasons", they broke backwards compatibility and
> > potentially packages throughout the universe of software development?
> > Augh...
> 
> Yes, I also think that this is very unfortunate.
> The performance "impact" is only visible in build processes and doesn't
> affect end users, and even there it is probably negligible for almost all
> packages.
> But at the time of the change reproducible builds weren't considered as
> that important yet and they probably didn't see any disadvantage in omitting
> the sorting.

ouch.

did someone already reported this to the make upstream developers as a
problem for reproducible builds everywhere?
 
> I think the best solution would be to change the default again to let
> wildcard sort the lists (it will probably make a bunch of packages
> reproducible without having to touch them). And if someone really
> needs this bit of extra-performance, a fast-wildcard or unsorted-wildcard
> could be added.

yup
 
& thanks for bringing this news to us!

-- 
cheers,
	Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20160323/1b146642/attachment.sig>