Et effectivement, une fois que tous les problèmes de reproductibilité seront corrigés (doux rêve), on pourra dire que re-builder depuis les sources est sans conséquence particulière pour le déterminisme du comportement du logiciel résultant.
Beaucoup de soucis de reproductibilité sont liés à des variables insérées dans le binaire lors de la compilation mais qui sont sans incidence fonctionnelle sur le résultat. Par exemple la date de la compilation, le nom de la machine qui a compilé, etc.
Ce n'est pas pour rien que Debian soit en avance sur le sujet par rapport à d'autres. Debian a une architecture de compilation qui repose sur les machines de ses empaqueteurs contrairement à d'autres où c'est centralisé sur les serveurs du projet comme Fedora. Le but de la reproductibilité est que quiconque puisse vérifier que le binaire obtenu depuis les dépôts correspond bien aux sources du projet et suivant les instructions de l'empaqueteur.
Car il est bien plus aisé pour un être malveillant de faire un acte nuisible dans le cas de Debian que dans le cas où c'est plus centralisé. Et probablement plus discret aussi. Car la sécurité de ces machines est moins contrôlée.
Le rapport avec Yocto, c'est sur les changements de l'environnement de build justement, pas des sources : Yocto rebuild au moindre changement d'environnement d'un soft tout l'OS, ce qui donne des résultats binaires différents à chaque fois car ils ne se concentrent pas sur la reproductibilité.
Je ne comprends pas ce que tu veux dire.
Si tu changes la recette pour obtenir le GCC pour la compilation croisée, comme le GCC résultant va changer, il faut en effet tout refaire.
Mais si tu ne changes rien, Yocto va tout garder en place. Au boulot ce n'est pas vraiment un soucis à l'usage. Uniquement lors des MaJ de Yocto (changement de GCC, Glibc, noyau, etc.) cela nécessite une reprise de zéro.
Et si tu mets à jour ta Fedora qui a un nouveau GCC par exemple, rien à refaire non plus.
c'est qu'ils se basent sur la disponibilité des sources en lignes, en trackant par défaut les derniers git : niveau reproductibilité, faire comme ça en général c'est garanti que ça ne marche pas (les dépôts bougent, etc).
Bof non, en général le numéro de commit de référence est renseigné. Justement pour limiter le soucis que tu pointes.
[^] # Re: Un nouveau standard ?
Posté par Renault (site web personnel) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 3.
Beaucoup de soucis de reproductibilité sont liés à des variables insérées dans le binaire lors de la compilation mais qui sont sans incidence fonctionnelle sur le résultat. Par exemple la date de la compilation, le nom de la machine qui a compilé, etc.
Ce n'est pas pour rien que Debian soit en avance sur le sujet par rapport à d'autres. Debian a une architecture de compilation qui repose sur les machines de ses empaqueteurs contrairement à d'autres où c'est centralisé sur les serveurs du projet comme Fedora. Le but de la reproductibilité est que quiconque puisse vérifier que le binaire obtenu depuis les dépôts correspond bien aux sources du projet et suivant les instructions de l'empaqueteur.
Car il est bien plus aisé pour un être malveillant de faire un acte nuisible dans le cas de Debian que dans le cas où c'est plus centralisé. Et probablement plus discret aussi. Car la sécurité de ces machines est moins contrôlée.
Je ne comprends pas ce que tu veux dire.
Si tu changes la recette pour obtenir le GCC pour la compilation croisée, comme le GCC résultant va changer, il faut en effet tout refaire.
Mais si tu ne changes rien, Yocto va tout garder en place. Au boulot ce n'est pas vraiment un soucis à l'usage. Uniquement lors des MaJ de Yocto (changement de GCC, Glibc, noyau, etc.) cela nécessite une reprise de zéro.
Et si tu mets à jour ta Fedora qui a un nouveau GCC par exemple, rien à refaire non plus.
Bof non, en général le numéro de commit de référence est renseigné. Justement pour limiter le soucis que tu pointes.