Pourquoi utiliser sbuild sur pbuilder?

Il existe de nombreuses façons de construire des paquets Debian dans un environnement propre et reproductible. Deux des plus fréquemment utilisés sont pbuilder et sbuild. Personnellement, j'ai toujours utilisé pbuilder. Je trouve pbuilder beaucoup plus facile à utiliser et à entretenir. Je n'ai pas pu trouver de comparaison côte à côte des deux. Qu'est-ce que je rate?

Quels sont les avantages de l'utilisation de sbuild par rapport à pbuilder?

sbuild et pbuilder se sont développés au fil des ans pour avoir des fonctionnalités presque identiques, et au fur et à mesure que des fonctionnalités s'ajoutent à l'une ou l'autre, elles ont tendance à être rapidement adoptées par l'autre.

Comme l'empaquetage Debian est un format basé sur des politiques, c'est une aide importante pour déterminer si un problème de construction donné est un bogue dans l'implémentation du constructeur ou un problème avec le paquet en cours de construction pour avoir plusieurs implémentations d'un système de construction. Afin de maintenir cela, les principaux systèmes de construction doivent tous avoir de puissants partisans qui les soutiennent, dans un esprit de concurrence collaborative pour garantir que nous avons les mises en œuvre de politique disponibles les plus correctes.

Les mécanismes internes de sbuild et pbuilder diffèrent considérablement, donc précisément quels paquets sont extraits pour satisfaire les dépendances de construction ou comment ils sont extraits, le mécanisme précis par lequel les différentes cibles dans debian / rules sont appelées, etc. peut différer, provoquant quelques légères différences de comportement dans des cas très spécifiques pour certains packages. La plupart du temps, cela représente un bogue dans l'une ou l'autre implémentation, et reflète parfois un manque de clarté dans la politique de packaging: dans tous les cas, les changements de comportement doivent être résolus.

Les builds officiels dans Debian et Ubuntu utilisent sbuild (bien que ce ne soit souvent pas le sbuild disponible dans les archives), ce qui est considéré comme un avantage par certains développeurs, car ils sont plus confiants que leur configuration correspond à celle à laquelle leur paquet sera exposé lors de la construction, bien que si tout le monde le fait, nous perdons la capacité de distinguer les bogues dans la politique des bogues dans sbuild.

Historiquement, ma compréhension est que le développement de pbuilder s'est initialement concentré sur les besoins du développeur en tant qu'utilisateur final et que le développement de sbuild s'est initialement concentré sur les besoins des administrateurs de buildd et d'archivage. Récemment, ces priorités ont changé, car les gens ont construit des systèmes de gestion d'archives basés sur pbuilder et des outils de développement plus utiles à l'aide de sbuild.

Les deux outils (ou leurs dérivés proches couramment disponibles) prennent en charge le stockage des chroots sous forme d'archives tar, décompressées sur le système, dans des volumes séparés (avec des crochets disponibles pour un montage spécial: par exemple, des instantanés LVM), en utilisant des systèmes de fichiers en superposition, en utilisant une sémantique de copie sur écriture, etc. Les deux outils offrent des outils de ligne de commande triviaux pour rationaliser le cas commun (test-construire un package) et une sémantique de hook riche pour prendre en charge les cas complexes (grandes archives). Les deux fournissent un moyen de créer un environnement de test dans un chroot. En bref, les deux outils fournissent à peu près tout ce que vous pourriez penser que vous vouliez dans un outil de construction de packages (et les deux ont des amonts actifs heureux d'accepter les bogues et les correctifs).

En résumé: si vous êtes satisfait de pbuilder, continuez à l'utiliser. Si vous voulez jouer avec sbuild, n'hésitez pas. Le meilleur outil est celui que vous êtes à l'aise d'utiliser pour le genre de travail que vous faites.

Il est toujours dangereux d'être en désaccord avec Emmet, alors permettez-moi de commencer en reconnaissant que sa réponse est probablement plus correcte. Cependant, je trouve personnellement pbuilder plus convivial et plus performant.

Si vous utilisez Ubuntu 12.10 ou une version ultérieure, assurez-vous d'installer les excellents scripts pbuilder, qui sont un ensemble d' encapsuleurs extrêmement conviviaux autour de pbuilder brut.

Si vous êtes sur Ubuntu 12.04, vous pouvez installer les scripts pbuilder depuis le référentiel backports.

Maintenant, comparons et contrastons la convivialité des opérations équivalentes. Dans ces exemples, je vais parcourir l'utilisation d'un chroot ARM hébergé sur x86, mais les concepts s'appliquent toujours à un chroot x86 hébergé sur x86 également. N'oubliez pas, j'utilise les wrappers pbuilder-scripts.

Une chose à noter est que les scripts pbuilder implémentent un peu de convention, similaire à la façon dont Ruby on Rails prend certaines décisions pour vous afin que vous puissiez y aller rapidement. Je vais essayer de les signaler au fur et à mesure.

Créer un chroot

mk-sbuild --arch=armhf quantal

contre

# in addition to the chroot, creates a new, empty directory named ~/Projects/quantal-armhf
pcreate -a armhf -d quantal quantal-armhf

verdict: tie , les deux lignes de commande sont assez simples, et les deux peuvent prendre des options supplémentaires pour des cas d'utilisation plus sophistiqués si nécessaire. Cependant, notez le nouveau répertoire supplémentaire créé par pcreate.

Télécharger un package source

# standard debian/ubuntu method, works in any directory
apt-get source casper

contre.

# 'quantal-armhf' is the name of the chroot created earlier
# results in downloading package to: ~/Projects/quantal-armhf/casper/
pget quantal-armhf casper

verdict: léger avantage pour sbuild , car vous utilisez les meilleures pratiques standard debian / ubuntu. La convention utilisée par pget peut sembler étrange au premier abord, mais comme je travaille sur plusieurs packages sur plusieurs versions d'Ubuntu, j'aime l'organisation qu'elle impose. Notez également que la source apt-get extrait également la source partout où vous exécutez la commande, vous laissant avec * .orig.tar.gz, * .debian.tar.gz, * .dsc et le répertoire étendu, que je trouve personnellement pour être en désordre. La beauté de l'organisation arrive bientôt, je le promets.

Entrez dans le chroot, version éphémère

schroot -c quantal-armhf

contre.

ptest quantal-armhf

verdict: léger avantage pour pbuild , moins de caractères à taper est moins de caractères. Notez que dans cette version d'entrée du chroot, toutes les modifications que vous apportez ici seront perdues une fois que vous aurez quitté le chroot. Notez également que dans schroot, vous resterez un utilisateur normal alors qu'avec ptest, vous serez dans le chroot en tant qu'utilisateur root.

Entrez le chroot, enregistrez la version des modifications

sudo schroot -c quantal-armhf-source -u root

contre.

ptest quantal-armhf --save

verdict: léger avantage pour pbuild , moins de caractères et des arguments de ligne de commande plus intuitifs, à mon avis. Dans cette version de saisie du chroot, toutes les modifications que vous y apporterez seront enregistrées pour de futures invocations.

Construisez un paquet dans le chroot

debuild -S -sa -I -i
sbuild -A --arch armhf -d quantal-armhf /path/to/casper-1.315.dsc

contre.

# must be invoked when pwd is ~/Projects/quantal-armhf/casper/casper-1.315
pbuild

verdict: pbuild , nous voyons maintenant la première victoire significative lors de l'utilisation des conventions de pbuild. Il s'agit d'une commande simple et morte qui n'a rien d'autre à retenir, par rapport à la spécification de l'architecture, du nom de chroot et nécessitant un chemin vers un fichier * .dsc requis par sbuild. De plus, vous devez vous rappeler de générer un nouveau fichier * .dsc avec sbuild alors que pbuild le fera automatiquement pour vous.

Construisez le même paquet dans chroot, une deuxième fois

Dans l'exemple ci-dessus, sbuild et pbuild téléchargeront et installeront les build-deps dans leurs chroots respectifs. Cependant, pbuild enregistre les fichiers .deb téléchargés dans / var, donc si vous appelez pbuild une deuxième fois, vous n'avez pas besoin de télécharger à nouveau tous les build-deps (bien qu'ils doivent toujours être installés dans le chroot). sbuild ne met pas en cache les fichiers .deb (du moins pas par défaut), et par conséquent, vous devez télécharger à nouveau tous les build-dep en plus d'attendre qu'ils soient installés dans le chroot.

verdict: pbuild par un long shot. La mise en cache des build-dep est un excellent paramètre par défaut, et pbuild est assez intelligent pour détecter s'il existe une version plus récente d'un build-dep dans l'archive et tirera la nouvelle version si nécessaire. Pour un package complexe avec de nombreux build-deps, ce paramètre simple vous fera économiser des minutes de votre vie.

Sommaire

Hors de la boîte, je trouve que les scripts pbuilder sont beaucoup plus conviviaux et plus rapides que les équivalents sbuild. Bien sûr, il existe des moyens de rendre pbuilder encore plus rapide (construire dans un tmpfs, désactiver certains des crochets chroot), et il y a probablement les mêmes astuces pour sbuild aussi, mais je ne les connais pas.

J'espère que cela t'aides.