Nous démarrons aujourd’hui la production d’un buildsystem Debian hébergé, en version beta : hubs. Cet article présente pourquoi.


Cela fait plusieurs mois qu’entre autres, nous installons et révisons des buildsystems Debian pour plusieurs de nos clients. Des grands et de plus jeunes. Ils en avaient grand besoin. Et ils en sont très contents.

Qu’est-ce qu’un buildsystem (BS), me direz-vous ? C’est l’ensemble de la chaîne d’outils (compilation, tests, packaging) qui vous permet de transformer le code source d’un logiciel en un “paquet” directement et facilement installable sur votre système d’exploitation.

Chaque distribution Linux a son buildsystem, adapté, personnel. C’est un gage de qualité d’intégration au système des logiciels empaquetés de cette façon.

Lorsque vous êtes éditeur de logiciel et voulez voir votre outil installé sur plusieurs distributions, vous voudrez l’intégrer via chacun de ces buildsystems, plutôt que via un outil maison. C’est plus sûr, plus propre, plus solide. Mais aussi un brin répétitif, pour chaque distribution.

La mise en place, et la maintenance, de toute cette usine logicielle est quand même un peu lourde. Et des développeurs, des éditeurs qui packagent, ou voudraient packager, leur logiciel pour une, ou plusieurs distributions, il y en a. Donc comment font-ils ?

Sonder

Pour le savoir, il y a quelques semaines, nous avons monté un très simple questionnaire : comment packagent-ils, quels sont leurs outils, sont-ils satisfait de cette manière de faire, utiliseraient-ils un service hébergé pour ce faire et pourquoi ?

Nous n’avons pas eu énormément de réponses (une cinquantaine en tout). Et bien sûr, c’est un questionnaire qui serait largement perfectible. Mais c’est suffisant pour nous à ce stade, pour nous faire une idée un peu plus claire.

D’abord, que pouvons-nous tirer de ces réponses ?

  • Tout le monde package d’abord en local, rien d’étonnant ; certains, mais pas si nombreux, re-packagent ensuite en ligne, sur des BS dédiés ou existants.
  • Les 2/3 sont satisfaits de leur façon de packager (uniforme FR/EN). C’est pratique, ça juste fonctionne, c’est custom, c’est automatisé, pour des besoins limités, c’est simple.
  • 1/3 n’est PAS content :
    • d’abord, l’installation et la maintenance de la chaîne de compilation/build, c’est compliqué, c’est lourd, et ça n’est pas le métier du packageur.
    • les policy de packaging sont complexes, il y a beaucoup d’outils, de pratiques à suivre, et les packageurs ne sont pas sûrs de faire bien.
    • les BS officiels poussent systématiquement les packages buildés sur les dépôts officiels. Ce n’est pas forcément ce que veulent les packageurs.
    • les gros packages sont lourds/lents à compiler/tester en local.

Est-ce que ces packageurs utiliseraient un BS hébergé ?

On a 50% de oui, 50% de non – plus précisément, les 2/3 des francophones répondent non, quand les 2/3 des anglophones répondent oui.

Les raisons de ceux qui n’envisagent pas d’utiliser un service hébergé se regroupent en trois ensembles (par ordre d’importance décroissante) :

  • ils ont déjà ce qu’il leur faut, packagent dans leur coin ou utilisent des services déjà existants (le BS Debian, OBS) ;
  • ils n’en voient pas l’intérêt ;
  • ils ont besoin de confiance dans l’infrastructure, de sécurité, de confidentialité de leur code source ;
  • ils n’en connaissent pas.

Les autres seraient intéressés par un tel service :

  • pour porter leur logiciel vers d’autres architectures (on ne peut pas tout avoir chez soi, hélas),
  • pour la simplicité de mise en œuvre et d’apprentissage du packaging,
  • pour gagner du temps (en mise en place, en maintenance, en reproductibilité et en temps de compilation),
  • pour la possibilité de connecter ce service à d’autres en ligne (tous n’ont pas répondu, mais on a des utilisateurs notamment de GitHub, Dropbox, Sourceforge, Travis-CI parmi les répondants).

Dans les grandes lignes. Vous pouvez consulter le détail des réponses.

Et donc ?

Il y a des solutions qui existent déjà en effet : des outils pour packager en local ou monter sa propre usine de compilation/packaging chez soi, plus ou moins équivalente à celle d’un projet Linux officiel, jusqu’à des systèmes comme OBS ou Project builder. Tout le monde ne les utilise pas. Beaucoup packagent d’abord chez eux, sur leur poste de travail.

Nous pensons qu’il y a encore de la place pour faire un service encore un brin différent : plus simple, direct, pédagogique, à destination des développeurs, reprenant exactement la même infrastructure que chaque distribution.

Nous allons donc continuer notre expérience avec hubs, un buildsystem Debian hébergé, reprenant l’infrastructure du buildsystem Debian officiel.

Il évoluera. Il est déjà fonctionnel, en version beta. Nous ouvrons les accès progressivement – si vous éditez un logiciel et/ou packagez des logiciels pour Debian, inscrivez-vous : nous vous ferons signe dès l’ouverture de votre compte !