Re: reproducibility

[Federico Beffa <beffa@ieee.org>]

On Wed, Jan 13, 2016 at 2:56 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> On Tue, Jan 12, 2016 at 10:37 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> Federico Beffa <beffa@ieee.org> skribis:
>>>
>>>> On Sun, Jan 10, 2016 at 9:49 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>>>> Federico Beffa <beffa@ieee.org> skribis:
>>>>>
>>>>>> I've noticed that a derivation is a function of the order of the
>>>>>> inputs. As an example, the following two input orders give rise to two
>>>>>> distinct derivations:
>>>>>>
>>>>>> A)
>>>>>>
>>>>>>     (inputs
>>>>>>      `(("texlive" ,texlive)
>>>>>>        ("texinfo" ,texinfo)
>>>>>>        ("m4" ,m4)
>>>>>>        ("libx11" ,libx11))
>>>>>>
>>>>>> B)
>>>>>>     (inputs
>>>>>>      `(("texinfo" ,texinfo)
>>>>>>        ("texlive" ,texlive)
>>>>>>        ("m4" ,m4)
>>>>>>        ("libx11" ,libx11))
>>>>>>
>>>>>> Is this intentional?
>>>>>
>>>>> Yes.  There are several places where order matters, most importantly
>>>>> search paths, and these are computed from the input lists.
>>>>
>>>> If order matters, it would probably be more robust to force internally
>>>> a specific order rather than relying on the (often random) order
>>>> defined in a package recipe (possibly created by an importer, ...).
>>>
>>> Most of the time any order would work, but I can imagine situations
>>> where the packager could purposefully choose a specific order.  So I’d
>>> rather not do any automatic sorting, if that’s what you have in mind.
>>
>> Just out of curiosity, could you provide a concrete example where the
>> order is purposefully specified.
>
> No specific example, sorry, but it’s plausible IMO.  With enough CPU
> power, we could try rebuilding everything with a random order and see
> what breaks.

I guess that's not necessary... I was just trying to learn something.

Thanks,
Fede