Vérifier les paquets Buildroot assistés par IA : dépendances, compilation croisée et builds propres

La génération de paquets Buildroot assistée par IA inspire davantage confiance lorsque la revue pose une question exigeante : le paquet se construit-il dans un répertoire de sortie vide sur un hôte documenté, et son binaire fonctionne-t-il dans l’image prévue ? Une compilation incrémentale sur le poste du développeur peut masquer dépendances absentes, bibliothèques hôtes et fichiers anciens.

Cet article utilise une application fictive de compression de journaux, fieldlog, composée d’un seul fichier. Les recettes défectueuse et corrigée sont des exemples pédagogiques construits, pas le résultat d’un outil d’IA exécuté. Aucun build Buildroot, essai sur cible ni résultat de reproductibilité n’est revendiqué. Adaptation et essais sont nécessaires avant emploi.

1. Fournir le contrat de construction, pas seulement le dépôt

Donnez à l’assistant la version ou le commit exact de Buildroot, la structure br2-external, le defconfig de carte, l’architecture, la libc, le compilateur et les correctifs du projet. Fournissez instructions de construction, révision source, fichiers de licence, bibliothèques requises et configuration d’exécution. Identifiez Make, CMake, Meson, Autotools ou la procédure spécifique réellement utilisée, au lieu de demander generic-package par habitude.

Dans ce scénario, supposons un arbre br2-external nommé FIELD contenant fieldlog.c revu et un fichier LICENSE MIT. Le programme dépend de zlib et ne nécessite aucun utilitaire hôte généré. Son source local est versionné avec l’arbre externe. Ces hypothèses définissent l’exemple, pas une application client existante.

Demandez Config.in, la recette, les modifications d’intégration de l’arbre externe, l’explication des dépendances hôte/cible et un plan de build propre. L’assistant doit signaler les incertitudes de licence ou de dépendance, sans les deviner. Excluez des entrées identifiants privés, secrets de déploiement et sources propriétaires sans rapport.

2. La recette défectueuse peut sembler fonctionner

# Deliberately flawed generated-style recipe.
FIELDLOG_SITE = $(BR2_EXTERNAL_FIELD_PATH)/package/fieldlog/src
FIELDLOG_SITE_METHOD = local

define FIELDLOG_BUILD_CMDS
	gcc -I/usr/include $(@D)/fieldlog.c -lz -o $(@D)/fieldlog
endef

define FIELDLOG_INSTALL_TARGET_CMDS
	cp $(@D)/fieldlog $(TARGET_DIR)/usr/bin/
endef

$(eval $(generic-package))

Le compilateur est le gcc de l’hôte et le chemin d’inclusion sélectionne explicitement ses en-têtes. -lz peut donc lier une bibliothèque hôte. Sur un poste de même architecture, le résultat peut sembler convaincant tout en utilisant une libc, un chargeur ou une ABI inadaptés à la cible. Sur un autre hôte, il peut simplement échouer.

Aucune dépendance de construction zlib n’est déclarée. La réussite peut tenir au fait qu’un autre paquet a placé la bibliothèque cible nécessaire dans staging lors d’un build antérieur. La recette suppose aussi l’existence du répertoire destination et ne fixe pas explicitement les permissions installées. Copier un binaire dans output/target ne prouve pas sa présence dans l’image finale du système de fichiers racine.

Le brouillon omet l’identité du source et les métadonnées de licence. Un répertoire local n’est pas immuable : une modification non commitée change le binaire sans changer la recette. Ces omissions passent facilement inaperçues si la revue consiste uniquement à demander au même assistant si sa recette est correcte.

3. Expliciter dépendances de configuration et de construction

# Config.in: illustrative single-file application using zlib.
config BR2_PACKAGE_FIELDLOG
	bool "fieldlog"
	select BR2_PACKAGE_ZLIB
	help
	  Example log-compression utility.

# fieldlog.mk: assumes the reviewed example source carries MIT.
FIELDLOG_VERSION = 1.0
FIELDLOG_SITE = $(BR2_EXTERNAL_FIELD_PATH)/package/fieldlog/src
FIELDLOG_SITE_METHOD = local
FIELDLOG_LICENSE = MIT
FIELDLOG_LICENSE_FILES = LICENSE
FIELDLOG_DEPENDENCIES = zlib

define FIELDLOG_BUILD_CMDS
	$(TARGET_CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) 		-o $(@D)/fieldlog $(@D)/fieldlog.c 		$(TARGET_LDFLAGS) -lz
endef

define FIELDLOG_INSTALL_TARGET_CMDS
	$(INSTALL) -D -m 0755 $(@D)/fieldlog 		$(TARGET_DIR)/usr/bin/fieldlog
endef

$(eval $(generic-package))

La correction emploie compilateur et options de la cible, déclare zlib avant la construction et crée le chemin d’installation avec des permissions explicites. Elle se limite volontairement à un fichier source. Une vraie application disposant de son propre système de build doit utiliser l’infrastructure Buildroot adaptée plutôt qu’accumuler une construction manuelle parallèle dans sa recette.

Le manuel Buildroot distingue sélection de configuration et ordre de construction : activer une bibliothèque dans Config.in ne remplace pas la dépendance .mk nécessaire à cet ordre. Il distingue aussi outils hôtes et paquets cibles. Examinez séparément ces deux graphes, y compris contraintes transitives de toolchain, fonctions optionnelles et exécutables devant tourner pendant le build.

Le fragment suppose que external.desc, le Config.in principal et external.mk intègrent déjà le paquet. Vérifiez cette intégration et les symboles exacts de la version retenue. La déclaration MIT n’est valable que pour le source fictif indiqué ; un texte généré ne prouve pas la licence d’un vrai dépôt. Conservez le fichier réel et examinez séparément les composants embarqués.

4. Examiner toutes les frontières où l’hôte peut contaminer le résultat

Cherchez dans le diff et la sortie détaillée du compilateur des chemins absolus d’en-têtes ou bibliothèques hôtes, gcc ou pkg-config non qualifiés, et des commandes exécutant des binaires cibles fraîchement construits. Un générateur hôte peut être légitime, mais exige sa construction hôte séparée et une dépendance explicite. Renommer un exécutable cible n’en fait pas un outil hôte.

Examinez comment le build amont reçoit CC, AR, options, sysroot et détection des dépendances. Ne remplacez pas aveuglément tous les chemins : certains outils doivent fonctionner sur l’hôte. Exigez l’activation ou désactivation explicite des bibliothèques optionnelles, pour que le poste développeur ne modifie pas silencieusement les fonctions. Si le paquet installe un démon, examinez séparément utilisateur, répertoires, configuration et système init choisi.

Lisez l’en-tête ELF, l’interpréteur et les dépendances dynamiques avec les utilitaires de la chaîne d’outils retenue. Vérifiez architecture, ABI et chargeur face à l’image, puis présence des bibliothèques partagées nécessaires dans le système cible. Ces contrôles réduisent le risque ; le binaire doit encore être essayé dans son environnement d’exécution prévu.

5. Utiliser une sortie réellement vide pour la réception

# Proposed acceptance build; paths/names are project placeholders.
# Choose a NEW, empty output path rather than deleting prior evidence.
make O=/work/out-fieldlog-clean BR2_EXTERNAL=/work/field   <board_defconfig>
make O=/work/out-fieldlog-clean BR2_EXTERNAL=/work/field
make O=/work/out-fieldlog-clean BR2_EXTERNAL=/work/field legal-info

# Inspect the resulting binary with the selected toolchain's readelf:
<target-readelf> -h -l -d /work/out-fieldlog-clean/target/usr/bin/fieldlog

Ces commandes sont proposées avec des paramètres de projet, pas présentées comme un journal de build. Enregistrez environnement hôte, commits Buildroot et arbre externe, defconfig sauvegardé, révisions source et correctifs locaux. Pour les sources téléchargées, vérifiez URL et empreintes selon les conventions de la version choisie. Pour cet exemple local, imposez un arbre source propre et une identité de révision conservée ; une chaîne de version ne fixe pas les octets.

Le manuel explique qu’un rebuild de paquet est incrémental et ne recrée pas lui-même l’image du système racine. Utilisez-le comme raccourci de développement, puis exécutez le build complet d’image nécessaire à la réception. Une nouvelle sortie est particulièrement utile après changement de dépendances, toolchain ou configuration, car elle supprime l’appui accidentel sur d’anciens artefacts.

Conservez le journal du build propre échoué si une dépendance manque, corrigez les entrées déclarées, puis répétez la même procédure. Ne faites pas disparaître le problème en ajoutant des paquets de développement hôtes, sauf s’ils sont des prérequis documentés. Copier manuellement une bibliothèque manquante dans la cible masquerait le défaut de paquetage.

6. Définir les preuves de paquetage, d’exécution et de répétabilité

• Test des dépendances : construire la configuration minimale prévue dans une sortie vide. Les preuves attendues comprennent les journaux ordonnés des dépendances et une image finale construite sans bibliothèques hôtes non déclarées.
• Test des artefacts : inspecter le binaire et le système de fichiers réellement empaqueté. Vérifier permissions d’exécution, chemin, chargeur et bibliothèques. Conserver l’empreinte de l’image utilisée sur cible.
• Test fonctionnel : compresser une entrée connue, la décompresser par une voie indépendante approuvée et comparer les octets. Couvrir entrée vide, données mal formées, sortie non inscriptible et stockage plein avec codes de sortie définis.
• Test du cycle de vie : si le paquet réel comprend un service, tester démarrage au boot, arrêt, redémarrage, permissions et échec de configuration. N’ajoutez pas un service uniquement parce qu’un brouillon d’IA le propose.
• Test de répétabilité : repartir des entrées enregistrées dans un autre environnement propre. Si l’identité octet par octet est exigée, comparer les empreintes et examiner horodatages, chemins et métadonnées générées. Un second build réussi ne suffit pas à prouver une reproductibilité bit à bit.

7. Accepter un paquet vérifiable, pas une explication persuasive

La remise finale doit inclure diff du paquet, identité du source, justification des dépendances, preuves de licence, procédure de build propre, journaux et résultats sur cible. Les essais d’exécution en attente doivent rester indiqués comme tels. L’IA aide à rédiger et à trouver les questions ; la décision de réception repose sur les preuves liées à l’image livrée.

Le service de diagnostic firmware et BSP d’Obeita concerne aussi la revue du système racine et de l’intégration. Le projet de passerelle Linux RK3506J fournit un contexte applicatif embarqué voisin ; il n’établit pas que fieldlog, Buildroot ou un paquet généré par IA ont été utilisés dans cette livraison.