Я запланировал последовательные обновления пакета debian, который у меня есть для внутреннего использования на нескольких серверах.
Теперь обновления должны происходить одно за другим в разное время, и некоторые серверы могут перейти на несколько версий, поэтому нельзя предполагать, что обновления произошли для данного сервера.
Итак, я знаю основы упаковки Debian, но могу пропустить некоторые дополнительные функции, которые могли бы мне здесь помочь.
Моя единственная идея на данный момент - иметь довольно сложные сценарии preinst и postinst, которые полностью обрабатывают весь диапазон старых и новых версий.
Есть идея получше?
Выступая в качестве разработчика Debian, как правило, у вас будет только одна версия пакета в архиве, поэтому наличие нескольких версий, которые нужно было бы устанавливать последовательно, не было бы идеальным или чем-то близким к элегантному решению. Сценарии до и после установки могут использоваться для автоматизации некоторых функций обновления, но вам нужно будет поддерживать этот сценарий близко между версиями, чтобы это работало должным образом, и потенциально может вызвать проблемы, если вы попытаетесь удалить или перейти на более раннюю версию, если вы не выполнили надлежащую проверку скрипты.
Если у вас есть изменения, которые необходимо поддерживать отдельно, чтобы обеспечить их выполнение, чтобы вы могли использовать главный «мета» пакет, который может быть установлен и зависит от последнего фактического пакета. Затем вам нужно будет создать отдельные пакеты для каждого изменения и установить соответствующие элементы управления, чтобы обеспечить надлежащий порядок. Это потребует хорошего знания Политика Debian выполнить, уделив особое внимание разделу 5.6.10 на отношениях пакетов, как вам нужно Pre-Depend на предыдущих пакетах обновлений.
Отдельные пакеты могут потребовать больше работы, но позволят вам делать что-то постепенно, но наиболее идеальным вариантом было бы, чтобы пакет мог автоматически идентифицировать и вносить необходимые изменения. Если файлы конфигурации еще не используются ucf это было бы целесообразно, поскольку это упростило бы управление ими в пакете, если бы вручную изменения / обновления выполнялись позже.
Редактировать обновление:
Когда я вернулся, чтобы перечитать это после сна, я заметил, что вы говорили об обновлении базы данных. В этом случае я думаю, что упаковка могла бы быть намного проще, если бы сама ваша база данных имела некоторую форму схемы управления версиями, а последовательные обновления находятся в отдельных файлах, которые необходимо выполнять только для баз данных. Тогда останется только добавить новый файл команд для выполнения в упорядоченном виде на основе той версии, которая хранится в таблице базы данных. Это больше не обязательно проблема упаковки как проблема администрирования базы данных. Все, что требуется от пакета, - это иметь надлежащие пре- и пост-сценарии для проверки существующей версии базы данных и выполнения необходимых сценариев команд SQL в пакете, чтобы обновить ее.