Як запустити скрипт лише під час першої установки пакета та під час оновлення?


14

Нещодавно я почав упакувати частину свого програмного забезпечення та публікувати його на Launchpad. Установка та видалення працює чудово, але оновити пакетну форму однієї версії до наступної - проблематично.

Проблема полягає в тому, що є деякі сценарії, які потрібно запустити лише під час першої установки пакета. Ці сценарії заповнюють БД, створюють користувача тощо. Зараз вони викликаються в розділі package.postinst configure). Однак це призводить до того, що вони викликаються під час оновлення, а також показані на діаграмі .

Чи є спосіб включити скрипт підтримки в пакет .deb, який виконується лише під час першої установки пакета, а не під час оновлення? Або яким було б елегантним способом включити кілька початкових сценаріїв налаштування в пакет .deb?

Відповіді:


15

З debian/preinstфайлом ви можете виконувати дії з встановлення, але не оновлення.

#!/bin/sh
set -e

case "$1" in
    install)
        # do some magic
        ;;

    upgrade|abort-upgrade)
        ;;

    *)
        echo "postinst called with unknown argument \`$1'" >&2
        exit 0
        ;;
esac

#DEBHELPER#

exit 0

Хоча, як випливає з назви, це виконується до встановлення вашого пакета. Тож ви тут не зможете зробити те, що вам потрібно. Більшість пакетів просто тестують на етапі налаштування, postinstякщо користувач вже створений. Ось осьcolord

$ cat  /var/lib/dpkg/info/colord.postinst
#!/bin/sh

set -e

case "$1" in
    configure)

# create colord group if it isn't already there
    if ! getent group colord >/dev/null; then
            addgroup --quiet --system colord
    fi

# create the scanner group if it isn't already there
    if ! getent group scanner >/dev/null; then
        addgroup --quiet --system scanner
    fi

# create colord user if it isn't already there
    if ! getent passwd colord >/dev/null; then
            adduser --system --ingroup colord --home /var/lib/colord colord \
        --gecos "colord colour management daemon"
        # Add colord user to scanner group
        adduser --quiet colord scanner
    fi

# ensure /var/lib/colord has appropriate permissions
    chown -R colord:colord /var/lib/colord

    ;;
esac    



exit 0

28

Перегляньте цю діаграму з вікі Debian про те, як називаються сценарії технічного обслуговування: Блок-схема сценарію підтримки для Debian

Якщо ви слідуєте ліворуч (шлях "усе йде нормально"), ви побачите, що postinstсценарій викликається з останньо налаштованою версією. Це дає змогу розрізнити оновлення та нову інсталяцію - у випадку оновлення ваш постінвест буде називатися як

postinst configure 1.23-0ubuntu1

де 1.23-0ubuntu1раніше встановлена ​​версія вашого пакета, тоді як для нового встановлення він буде називатися як

postinst configure

Це також дозволяє вам обробляти випадок, коли вам потрібно виконати дію під час оновлення до певної версії - ви можете перевірити postinstцю версію.

Це дозволяє легко перевірити, чи виконується сценарій під час встановлення чи «оновлення». Якщо $ 2 недійсне, то це встановлення. так:

if [ -z "$2" ]; then
  do install stuff
else
  do upgrade stuff
fi

1
Зауважте, що додатковий параметр також передається у випадку, якщо ви вилучили пакунок (але не очистили його) та встановите його знову.
скачав

3

Можливо, ви зможете використовувати сценарій debian / preinst у поєднанні з postinst.

У сценарії preinst перевірте, чи не встановлено файл, який ваш pkg точно встановлено. Якщо він присутній, нічого не робіть (тому що ваш пакет був раніше встановлений), в іншому випадку виконайте кроки налаштування.

Якщо ваші кроки налаштування вимагають, щоб ваш кг був встановлений (у такому випадку вищезазначене не працюватиме, оскільки преінтест працює перед встановленням), тоді ваш сценарій preinst може написати файл, наприклад: / tmp / setupmypkg. Ваш поштовий скрипт може просто перевірити, чи є цей файл, і якщо так, зробіть дві речі:

  • ваші початкові кроки налаштування
  • видаліть файл / tmp / setupmypkg

1
Так, це спрацювало б, і я зараз роблю щось подібне. Але це все ще виглядає трохи хакітно ... Я сподівався на більш рідний спосіб це зробити. Це не здається таким екзотичним запитом?
Jeroen

1

Я виявив, що тестування на $ 2 у вашому скрипті "postinst configure" не працює належним чином, якщо ви вже встановили свій пакет один раз раніше, потім видалили його (але без очищення), а потім спробуйте перевстановити ще раз. У цьому випадку сценарій postinst все ще отримує аргумент версії для кроку "налаштування postinst".

Однак якщо ви встановили пакет раніше, видаліть І очистіть його, а потім знову встановіть, сценарій "postinst configure" НЕ отримає аргумент версії в $ 2


0

Я не думаю, що так, але ви можете легко змінити сценарії preinst / postinst, щоб перевірити, чи встановлюється пакет вперше, і вжити стандартних заходів.

Може бути щось подібне,

в прейнст.

if not is_package_istalled():
    export MY_PACKAGE_FIRST_INSTALL

постінст,

if MY_PACKAGE_FIRST_INSTALL:
    Do First Install Setup 

Редагувати

Хм, може, ви можете просто перевірити все це безпосередньо в postinst, тому що я думаю, що dpkg не встановив би статус пакету, встановленого перед виконанням postinst, але я не впевнений. Отже, вищезгадане могло б прийти,

постінст,

if not is_package_istalled():
    Do First Install Setup 

Де, ви можете функціонувати для встановлення стану інсталяції is_package_installed. Це може бути щось на кшталт "dpkg --statusname name"

АБО

Чому б просто не перевірити, чи є зміни, які ви хочете внести, вже є, а продовжувати їх лише, якщо їх немає.


Я не розумію. Звідки береться IS_INSTALLED?
Jeroen

Немає IS_INSTALLED, це лише псевдо-код. Просто приклад. IS_INSTALLED може бути результатом такої команди, як 'dpkg --status package_name'. Я мав на увазі те, що ви можете перевірити, чи встановлений пакет у preinst, встановити var var, а потім на основі цього var стану виконувати дії в postinst.
Owais Lone
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.