-
@Metal3d @dagon_fr @waxzce @EricLeVacon @briceatwork Non. Tu ne sais pas détecter la présence d’un sqlite3 impliqué par une dépendance Go quelque part. C’est impossible. Il n’y a aucun outil pour faire ça. Et à toi de me prouver le contraire.
-
@Metal3d @dagon_fr @waxzce @EricLeVacon @briceatwork Tu peux au mieux lister les deps go. Ça ne t’affichera pas forcément libsqlite3. Encore moins la version embarquée en réalité. Ça sera encore plus difficile à faire à partir du binaire final une fois déployée en prod.
-
@Metal3d @dagon_fr @waxzce @EricLeVacon @briceatwork Faudra détecter l’image utilisée. Remontée au source du build docker. Lire le dockerfile. Remonter aux masters *de l’époque* du build go. Pour espérer détecter que « ah oui, crypto/tls de go embarque libssl et sqlite3.go embarque libsqlite2.so ». […]
-
@Metal3d @dagon_fr @waxzce @EricLeVacon @briceatwork Aller voir au moment du build quel était la version de libsqlite3.so réellement sur la machine. Etc. Tout ça, c’est à développer à la main, parce que rien n’existe. Quand moi, je me contente d’un « apt-cache show mon-paquet » pour lister explicitement et […]
-
@Metal3d @dagon_fr @waxzce @EricLeVacon @briceatwork exhaustivement la version exacte de toutes dépendances présentes pour faire ce paquet. Et je peux faire ça directement en désarchivant le .deb (dpkg -C doit me donner l’info aussi). Je n’ai même pas besoin d,avoir un système live sous la main.
-
@Metal3d @dagon_fr @waxzce @EricLeVacon @briceatwork Je n’ai pas besoin d’avoir les sources sous la main. Je n’ai pas besoin de remonter dans l’historique git au moment du build pour savoir ce que j’utilisais. Je n’ai besoin d’aucun tag ni référence. Le truc est 100% auto-porteur.
-
@Metal3d @dagon_fr @waxzce @EricLeVacon @briceatwork Et je n’ai absolument aucun outil custom à développer. Tout est fourni à 100% prêt et utilisable par le projet Debian. Battle testé par l’ensemble des mainteneurs de la communauté.
aeris22’s Twitter Archive—№ 74,237