Elle a pas beaucoup changé non. Mais c'est surtout le reste qui change.
Les problèmes qu'on a, c'est principalement avec des distrib récentes. C'est elles qui ont mise à jours leur lib (openssl, drivers, ...).
Qt a évolué aussi, on pourrait builder avec la dernière version de Qt (ce qui corrigerait probablement les problèmes avec les distrib récentes). Mais c'est pas dispo en pré-compilé sur les anciennes distrib. Et on veut compiler sur une ancienne distrib pour avoir une vieille version des glibc et stdlibc++.
Alors on pourrait effectivement recompiler Qt dans notre CI sur en vieille machine. Mais ça passerait pas dans notre CI (on fait quand même des builds toutes les nuits et on publie les nigthly)
On pourrait avoir notre propre runner au lieu d'utiliser celui fournit par github mais il faut des €€ pour ça (et rajouter de la maintenance d'une nouvelle machine)
Ou alors je fais un build en local chez moi et on utilise ça dans notre CI... mais quid de la sécu et de la reproductibilité ?
Ou alors je change de métier et je deviens packageur (et plus développeur) et je m'amuse a maintenir une version récente de Qt sur des vieille distrib.
Ou alors ...
Et puis il y a pas que Qt. gtest impose C++14 maintenant, mais on est encore en C++11. Il faut qu'on change on est d'accord. Mais en attendant on compile avec une vieille version de gtest. Sauf que les packageurs (merci à eux pour leur travail), ils utilisent le gtest de la distrib et bim, ça compile plus sur les machines récentes.
C'est pas compliqué à changer, c'est une ligne de config (et les packageurs patche cette ligne). Mais il faut vérifier que tous les compilo qu'on utilise font correctement du C++14 avant.
Au milieu de tout ça, il faut faire du code review, répondre aux issues sur github, faire la maintenance de tous les jours et rajouter des fonctionnalités et améliorer les perfs.
À un moment il faut faire des choix.
Le problème c'est qu'on est dans un monde qui bouge et on doit bouger avec lui. (Même si je préfèrerait faire les trucs dans mon coin sans jamais mettre à jour les dépendances).
J'ai l'impression que des fois vouloir avoir un binaire qui satisfait à toutes les distribs est plus compliqué que profiter des infras comme le opensuse build service qui te permet de faire des paquets individuels pour toutes les grandes distribs.
J'ai jamais utilisé. Mais j'ai peur que ça soit là aussi pas la panacée. On va se retrouver avec plusieurs paquets, compilés avec différentes version des dépendances et différentes options. Et on sait qu'on a des bugs dans nos dépendances qui sont fixé avec des versions récentes. Donc on sait que nos logiciels vont se comporter différemment d'un paquet à l'autre. Il va falloir suivre tout ça. On va pas pouvoir tout tester, donc on va fournir des paquets pour une distrib spécifique sans vraiment savoir si ça fonctionne. Il va falloir comprendre ce qu'il se passe au prochain rapport de bug... et au final c'est la même chose que maintenant mais avec une couche de plus.
Mon métier c'est développeur. Pas packageur. C'est pas à moi de faire le packaging. Mais on fait quand même un binaire pour que les gens normaux (pas les gens qui participent à cette discussion ici) puisse utiliser kiwix sans avoir à tout recompiler.
Et du coup, on a des gens qui viennent nous dire qu'on est fainéant parce que le binaire est trop gros alors qu'on pourrait ne rien faire. D'ailleurs on leur impose rien, ils peuvent toujours recompiler, on fournit même kiwix-build pour ça.
[^] # Re: Flatseal
Posté par GaMa (site web personnel) . En réponse au journal "dérives sécuritaires" : inconvénients des flatpacks, snap ou environnements sandbox.. Évalué à 6.
Elle a pas beaucoup changé non. Mais c'est surtout le reste qui change.
Les problèmes qu'on a, c'est principalement avec des distrib récentes. C'est elles qui ont mise à jours leur lib (openssl, drivers, ...).
Qt a évolué aussi, on pourrait builder avec la dernière version de Qt (ce qui corrigerait probablement les problèmes avec les distrib récentes). Mais c'est pas dispo en pré-compilé sur les anciennes distrib. Et on veut compiler sur une ancienne distrib pour avoir une vieille version des glibc et stdlibc++.
Alors on pourrait effectivement recompiler Qt dans notre CI sur en vieille machine. Mais ça passerait pas dans notre CI (on fait quand même des builds toutes les nuits et on publie les nigthly)
On pourrait avoir notre propre runner au lieu d'utiliser celui fournit par github mais il faut des €€ pour ça (et rajouter de la maintenance d'une nouvelle machine)
Ou alors je fais un build en local chez moi et on utilise ça dans notre CI... mais quid de la sécu et de la reproductibilité ?
Ou alors je change de métier et je deviens packageur (et plus développeur) et je m'amuse a maintenir une version récente de Qt sur des vieille distrib.
Ou alors ...
Et puis il y a pas que Qt. gtest impose C++14 maintenant, mais on est encore en C++11. Il faut qu'on change on est d'accord. Mais en attendant on compile avec une vieille version de gtest. Sauf que les packageurs (merci à eux pour leur travail), ils utilisent le gtest de la distrib et bim, ça compile plus sur les machines récentes.
C'est pas compliqué à changer, c'est une ligne de config (et les packageurs patche cette ligne). Mais il faut vérifier que tous les compilo qu'on utilise font correctement du C++14 avant.
Au milieu de tout ça, il faut faire du code review, répondre aux issues sur github, faire la maintenance de tous les jours et rajouter des fonctionnalités et améliorer les perfs.
À un moment il faut faire des choix.
Le problème c'est qu'on est dans un monde qui bouge et on doit bouger avec lui. (Même si je préfèrerait faire les trucs dans mon coin sans jamais mettre à jour les dépendances).
J'ai jamais utilisé. Mais j'ai peur que ça soit là aussi pas la panacée. On va se retrouver avec plusieurs paquets, compilés avec différentes version des dépendances et différentes options. Et on sait qu'on a des bugs dans nos dépendances qui sont fixé avec des versions récentes. Donc on sait que nos logiciels vont se comporter différemment d'un paquet à l'autre. Il va falloir suivre tout ça. On va pas pouvoir tout tester, donc on va fournir des paquets pour une distrib spécifique sans vraiment savoir si ça fonctionne. Il va falloir comprendre ce qu'il se passe au prochain rapport de bug... et au final c'est la même chose que maintenant mais avec une couche de plus.
Mon métier c'est développeur. Pas packageur. C'est pas à moi de faire le packaging. Mais on fait quand même un binaire pour que les gens normaux (pas les gens qui participent à cette discussion ici) puisse utiliser kiwix sans avoir à tout recompiler.
Et du coup, on a des gens qui viennent nous dire qu'on est fainéant parce que le binaire est trop gros alors qu'on pourrait ne rien faire. D'ailleurs on leur impose rien, ils peuvent toujours recompiler, on fournit même kiwix-build pour ça.
Matthieu Gautier|irc:starmad