On 05/18/2011 11:43 AM, Robert Schiele wrote: > On Wed, May 18, 2011 at 07:12:30AM -0700, John Reiser wrote: >> On 05/18/2011 05:19 AM, Robert Schiele wrote: >>> By just sorting the list of files to be processed we make the order >>> (and thus the build result) reproducable again. The sorting >>> criteria for this operation does not matter. >> >> Counterexample: sort by record number (thus output equals input.) >> >> Counterexample: any sort where two or more records have equal keys >> (thus output order is not unique.) > > Ok, point taken. My statement was meant in the sense that it does not matter > what the exact sort order is that the sort tool is creating, as long as it is > unique. But if I had known that people start nitpicking on that I would have > not added this additional statement. Within the last ten years there have been buggy versions of 'sort' which truncated alphanumeric keys at something like 63 bytes. So two distinct .rpm files whose names agreed in the first 63 bytes, and differed later, would compare equal, making the output order indeterminate. The point is, any deterministic unique output order will work. Unique keys [and consistent locale] are necessary to produce such output from 'sort'. -- _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
