J'ai un recette du Launchpad qui ressemble à ceci:
# git-build-recipe format 0.4 deb-version {latest-tag}-0~{time}~rev{revno}~pkg{revno:packaging}
lp:kvantum master
nest packaging lp:~krisives/kvantum/+git/kvantum-packaging debian master
Cependant, en amont préfixe les numéros de version avec un V
, ce qui amène le processus de création de package à se plaindre de ce que les versions doivent commencer par un nombre. L’auteur souhaite conserver ses noms de balises avec le préfixe V
.
Hormis la modification manuelle de la changelog
dans mon référentiel de conditionnement, existe-t-il un moyen de faire en sorte que la recette utilise automatiquement le {latest-tag}
sans interrompre le processus de construction?
Une solution de contournement consiste simplement à vous assurer que la partie de version en amont de votre version de package commence par un chiffre en l'insérant. Par exemple, vous pouvez utiliser:
# git-build-recipe format 0.4 deb-version 0{latest-tag}-0~{time}~rev{revno}~pkg{revno:packaging}
Notez que cela comparera moins que tout ce que vous avez déjà publié avec votre développement actuel, car par exemple, 0V1
est trié après V1
. Si vous le devez, vous pouvez utiliser une époque (par exemple, 1:0{latest-tag}-0~{time}~rev{revno}~pkg{revno:packaging}
) pour assurer un tri plus élevé que tout ce qui a été publié précédemment, mais cette bosse n'est pas réversible et doit donc être évitée dans la mesure du possible.
Pour plus d'informations:
Vous pouvez trouver une explication sur le fonctionnement des chaînes de version d’emballage dans section 5.6.1.2 de la politique Debian .
Vous pouvez trouver l'implémentation exacte des extensions de variable en commençant par le source du paquet paquet git-build-recipe .
Voir le documentation du fonctionnement des recettes , y compris détails sur les extensions de variable . Notez bien que cette documentation est vraiment pour les recettes basées sur bzr, et que l'implémentation de git est simplement documentée comme "similaire" (il y a un bogue ouvert sur ceci ).
Vous pouvez tester les comparaisons de chaînes de version de package avec dpkg --compare-versions
, par exemple dpkg --compare-versions 0V1 gt V1 && echo true || echo false
. Voir dpkg (1) pour plus de détails.
Je ne vois aucune option dans la documentation permettant de faire quoi que ce soit avec la "dernière balise en amont" sauf pour l'incorporer dans la chaîne de la version finale, ni aucun autre moyen de récupérer la version en amont si la balise est le seul endroit en amont pour la déclarer. . Par conséquent, je pense que ma solution de contournement, ou quelque chose du genre, est votre seule option pour le moment, mais nous pouvons voir si quelqu'un d'autre a d'autres réponses.
Si la solution de contournement ne vous convient pas, les rapports de bogues contre git-build-recipe sont les bienvenus , y compris pour les demandes de fonctionnalités destinées à couvrir de nouveaux cas d'utilisation tels que celui-ci. Je ne peux pas vous dire quelle sera la réponse quant aux améliorations qui conviendraient en général, cependant. Une amélioration permettant de fournir une substitution basée sur les expressions rationnelles dans une extension pourrait être possible, par exemple, mais devrait probablement être implémentée de manière à garantir que le code malveillant ne puisse pas être exécuté sur l'hôte exécutant git-build-recipe malgré les apparences. une entrée de recette non fiable. Il serait probablement préférable de trouver un accord sur un bogue avant de tenter d'implémenter une telle fonctionnalité.