Как я могу удалить префикс из {последнего тега} в рецепте Панели запуска?

У меня есть рецепт Панели запуска, который похож на это:

# 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

Однако восходящие префиксы номера версий с a V который заставляет упаковочный процесс жаловаться, что версии должны начаться с числа. Автор хочет сохранить его V снабженные префиксом имена тега.

Кроме ручного изменения changelog в моем упаковочном репозитории там способ иметь рецепт, автоматически используют {latest-tag} не повреждая процесс сборки?

3
задан 10 December 2018 в 20:14

1 ответ

Одно обходное решение должно просто удостовериться, что восходящая часть версии Вашей версии пакета действительно запускается с цифры путем вставки один. Например, Вы могли использовать:

# git-build-recipe format 0.4 deb-version 0{latest-tag}-0~{time}~rev{revno}~pkg{revno:packaging}

Обратите внимание, что это выдержит сравнение ниже, чем что-нибудь, что Вы, возможно, уже опубликовали со своим текущим расширением, однако, с тех пор например, 0V1 виды после V1. Если Вы должны, Вы могли бы использовать эпоху (например. 1:0{latest-tag}-0~{time}~rev{revno}~pkg{revno:packaging} для обеспечения это сортирует выше, чем что-либо опубликованное ранее, но этот удар не обратим и так должен избежаться если вообще возможный.

Для получения дополнительной информации:

Я не вижу опции в документации, чтобы сделать что-либо с "последним восходящим тегом" кроме встроить его в Вашу строку окончательной версии, ни любой другой способ захватить восходящую версию, если тег является единственным местом, в восходящем направлении объявляют это. Поэтому я думаю, что мое обходное решение или что-то как он, является Вашей единственной опцией в данный момент, но мы видим, есть ли у кого-либо еще какие-либо другие ответы.

Если обходное решение не приемлемо для Вас, отчеты об ошибках против рецепта сборки мерзавца приветствуются включая то, чтобы запросы новых функций покрыли новые варианты использования, такие как это. Я не могу говорить за то, чем ответ будет относительно того, какие улучшения подошли бы в целом, все же. Улучшение для обеспечения находящейся в regexp замены в расширении могло бы быть возможным, например, но должно будет, вероятно, быть реализовано способом, который гарантирует, что вредоносный код не может быть выполнен на хосте под управлением рецепт сборки мерзавца перед лицом недоверяемого входа рецепта. Вероятно, было бы лучше найти соглашение в ошибке сначала, прежде, чем попытаться реализовать такую дополнительную функцию.

2
ответ дан 1 December 2019 в 16:50

Другие вопросы по тегам:

Похожие вопросы: