# Глава 7. Продвинутые практики pkg-plist

Этот перевод может быть устаревшим. Для того, чтобы помочь с переводом, пожалуйста, обратитесь к Сервер переводов FreeBSD.

## 7.1. Изменение содержимого pkg-plist в зависимости от make-переменных

Некоторые порты, в частности, порты `p5-`, должны менять содержимое своих файлов pkg-plist в зависимости от того, с какими параметрами они были отконфигурированы (или в зависимости от версии языка `perl` в случае портов `p5-`). Чтобы облегчить этот процесс, любые вхождения ключевых слов `%%OSREL%%`, `%%PERL_VER%%` и `%%PERL_VERSION%%` в файле pkg-plist будут заменяться соответствующими значениями. Значением `%%OSREL%%` является номер версии операционной системы (например, `4.9`). `%%PERL_VERSION%%` и `%%PERL_VER%%` обозначают полный номер версии `perl` (например, `5.8.9`). Некоторые другие `%%VARS%%`, имеющие отношение к файлам документации порта, описаны в соответствующем разделе.

Если вам нужно сделать другие подстановки, вы можете указать в переменной `PLIST_SUB` список пар `VAR=VALUE`, и все вхождения `%%VAR%%` в файле pkg-plist будут заменяться на значение VALUE.

Например, если у вас имеется порт, который устанавливает много файлов в каталог, зависящий от версии, вы можете задать нечто типа

    OCTAVE_VERSION=	2.0.13
    PLIST_SUB=	OCTAVE_VERSION=${OCTAVE_VERSION}

в файле Makefile и использовать `%%OCTAVE_VERSION%%` везде, где нужно указать номер версии в файле pkg-plist. Таким образом, при обновлении порта вам не нужно будет менять десятки (а в некоторых случаях и сотни) строк в файле pkg-plist.

Если ваш порт устанавливает файлы в соответствии с установленными в порту опциями, то обычным способом управления является добавление префиксов `%%TAG%%` для строк pkg-plist с добавлением этого `TAG` в переменную `PLIST_SUB` внутри Makefile со специальным значением `@comment`, которое указывает пакетным инструментам игнорировать эти строки:

    .if defined(WITH_X11)
    PLIST_SUB+=	X11=""
    .else
    PLIST_SUB+=	X11="@comment "
    .endif

и в самом pkg-plist:

    %%X11%%bin/foo-gui

Эта подстановка будет сделана между выполнением целей `pre-install` и `do-install`, посредством чтения файла PLIST и записью в файл TMPPLIST (по умолчанию это файл WRKDIR/.PLIST.mktmp). Так что если ваш порт строит PLIST на лету, делайте это во время или до выполнения цели `pre-install`. Кроме того, если вашему порту требуется отредактировать получающийся файл, делайте это в цели `post-install` изменением файла TMPPLIST.

Другой способ изменения списка сборки порта основан на определении значений переменных `PLIST_FILES`, `PLIST_DIRS` и `PLIST_DIRSTRY`. Каждое из них рассматривается как перечень путей для записи в TMPPLIST содержимого PLIST. Имена, перечисленные в `PLIST_FILES`, `PLIST_DIRS` и `PLIST_DIRSTRY` подвергаются подстановке `%%VAR%%`, как описано выше. За исключением этого, имена из `PLIST_FILES` будут появляться в окончательном варианте перечня сборки без изменений, тогда как `@dirrm` и `@dirrmtry` будут соответственно предшествовать именам из `PLIST_DIRS` и `PLIST_DIRSTRY`. Для того чтобы изменения вступили в силу, `PLIST_FILES`, `PLIST_DIRS` и `PLIST_DIRSTRY` должны задаваться до того, как будет записываться TMPPLIST, то есть в цели `pre-install` или ещё раньше.

## 7.2. Пустые каталоги

### 7.2.1. Очистка пустых каталогов

Заставьте ваш порты удалять пустые каталоги при удалении. Обычно это достигается добавлением строк `@dirrm` для всех каталогов, которые создаются этим портом. Вам нужно удалить подкаталоги до того, как вы сможете удалить родительские каталоги.

     :
    lib/X11/oneko/pixmaps/cat.xpm
    lib/X11/oneko/sounds/cat.au
     :
    @dirrm lib/X11/oneko/pixmaps
    @dirrm lib/X11/oneko/sounds
    @dirrm lib/X11/oneko

Однако, иногда `@dirrm` будет выдавать ошибки, потому что другие порты используют тот же самый подкаталог. Вы можете использовать `@dirrmtry` для удаления только пустых каталогов без выдачи предупреждений.

    @dirrmtry share/doc/gimp

Эта команда не выведет никаких сообщений об ошибках и не вызовет аварийного завершения работы `pkg delete` (см. pkg-delete(8)), даже если каталог ${PREFIX}/shared/doc/gimp не пуст из-за того, что другие порты установили сюда какие-то файлы.

### 7.2.2. Создание пустых каталогов

Пустым каталогам, создаваемым во время установки порта, нужно особое внимание. Они не будут созданы при установке пакета, потому что пакеты содержат только файлы, а `pkg add` и `pkg install` создают для них каталоги по мере надобности. Чтобы убедиться, что пустой каталог создается при установке пакета, добавьте эту строку в pkg-plist перед соответствующей строкой `@dirrm`:

    @exec mkdir -p %D/shared/foo/templates

## 7.3. Конфигурационные файлы

Если ваш порт устанавливает конфигурационные файлы в каталог PREFIX/etc (или куда-то еще), не делайте их простого перечисления в файле pkg-plist. Это приведёт к тому, что по команде `pkg delete` или при новой установке файлы, тщательно отредактированные и настроенные пользователем, будут уничтожены.

Вместо этого установите файл(ы) с примерами с расширением filename.sample. Затем скопируйте файл с примером на место настоящего файла конфигурации, если таковой ещё не существует. При деинсталляции удаляйте файл конфигурации только в том случае, если он идентичен файлу с расширением .sample. Вам нужно управлять этим в Makefile и в pkg-plist (для установки из пакета).

Пример части Makefile:

    post-install:
    	@if [ ! -f ${PREFIX}/etc/orbit.conf ]; then \
    	${CP} -p ${PREFIX}/etc/orbit.conf.sample ${STAGEDIR}${PREFIX}/etc/orbit.conf ; \
    	fi

Добавьте по три строки в pkg-plist для каждого конфигурационного файла, как показано ниже:

    @unexec if cmp -s %D/etc/orbit.conf.sample %D/etc/orbit.conf; then rm -f %D/etc/orbit.conf; fi
    etc/orbit.conf.sample
    @exec if [ ! -f %D/etc/orbit.conf ] ; then cp -p %D/%F %B/orbit.conf; fi

Данные строки являются упорядоченными. На этапе удаления файл с примером сравнивается с рабочим конфигурационным файлом. Полное совпадение означает отсутствие каких-либо изменений в рабочем файле со стороны пользователя, и следовательно этот файл может быть безопасно удалён. Так как файл с примером всё ещё должен существовать для сравнения, строка `@unexec` следует перед именем файла с примером конфигурации. На этапе установки, если рабочий файл конфигурации отсутствует, он копируется из файла с примером. Файл с примером обязательно должен быть установлен до операции копирования, поэтому строка `@exec` следует после имени файла с примером конфигурации.

Для получения дополнительного отладочного вывода на экран можно временно удалить параметр `-s` из команды cmp(1).

Для получения дополнительной инфорации по использованию `%D` и прочих маркеров подстановки обратитесь к странице Справочника pkg-create(8).

Если существует действительно стоящая причина не устанавливать рабочий файл конфигурации по умолчанию, уберите строку `@exec` из pkg-plist и добавьте сообщение, указывающее на то, что пользователь обязан скопировать и отредактировать этот файл перед тем, как программное обеспечение начнёт работать.

## 7.4. Динамический или статический список упаковки

Статический список упаковки - это список упаковки, который доступен в Коллекции Портов или как файл pkg-plist (с подстановкой переменных или без неё), или как встроенный в Makefile посредством `PLIST_FILES`, `PLIST_DIRS` и `PLIST_DIRSTRY`. Даже если содержимое является автоматически порождаемым при помощи инструмента или в результате выполнения цели в Makefile до включения в Коллекцию Портов коммиттером, то список всё ещё будет считаться статическим, поскольку его можно узнать без необходимости скачивания или компиляции дистрибутива.

Динамический список упаковки это список упаковки, который получается во время компиляции порта и строится на основе устанавливаемых файлов и каталогов. Узнать такой список невозможно до того, как исходный код портируемого приложения будет скачен и скомпилирован, или после запуска `make clean`.

Хотя использование динамических список упаковки не запрещено, сопровождающие должны использовать статические списки упаковки везде, где это возможно, поскольку это позволяет пользователям выполнять grep(1) по доступным портам для обнаружения, например, который порт устанавливает определенный файл. Динамические списки должны быть использованы в основном для сложных портов, для которых изменения в списке упаковки кардинальным образом основаны на необязательных возможностях порта (и, таким образом, делая сопровождение статических списков упаковки невозможным), или портов, которые изменяют список упаковки на основе версии используемого им программного обеспечения (например, порты, которые порождают документы при помощи Javadoc).

## 7.5. Автоматическое создание списка упаковки

Первым делом убедитесь, что ваш порт практически полностью завершён и осталось создать только pkg-plist. После этого вы можете запустить `make makeplist` для автоматического создания pkg-plist. Содержимое этого файла должно быть дважды перепроверено.

Пользовательские конфигурационные файлы должны быть удалены или быть установлены как filename.sample. Файл info/dir включать в список не нужно, но должны быть добавлены соответствующие строчки install-info, так, как это описано в разделе о файлах в формате info. Все библиотеки, устанавливаемые портом, должны быть перечислены так, как это описано в разделе о динамических библиотеках.

Изменено: 9 марта 2024 г. by Danilo G. Baio

Назад
Главная
Далее