Что такое deb пакет
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
.deb — расширение имён файлов «бинарных» пакетов для распространения и установки программного обеспечения в ОС проекта Debian, и других, использующих систему управления пакетами dpkg. Deb — это часть слова Debian, в свою очередь, образованного от слов Debra — имени подруги (впоследствии — жены, ныне — бывшей) основателя Дебиана Яна Мердока и Ian от его собственного имени.
Содержание
Формат
Старый формат (до версии Debian 0.93)
deb-файл в старом формате представляет собой две строки ASCII-текста, за которыми следуют два сцепленных архива формата tar.gz. Первая строка содержит номер версии формата, дополненный до 8 цифр (0,939000 для всех старых форматов). Вторая строка содержит десятичную строку (без начальных нулей), определяющую длину первого архива формата tar.gz. Каждая из этих строк завершается одним символом новой строки. [Источник 1]
Новый (текущий) формат (с версии Debian 0.93)
Начиная с Debian версии 0.93, deb файл представляет собой архив формата ar.
Обычно архив содержит 3 файла в нижеприведенной последовательности:
Сontrol.tar
Архив содержит набор файлов:
Программное обеспечение
Стандартная программа для управления этими пакетами — dpkg, часто используемая с помощью apt и aptitude.
Deb-пакеты могут быть преобразованы в другие пакеты, и наоборот, с помощью программы alien.
Создают пакеты deb обычно с помощью утилит dpkg — в частности, dpkg-buildpackage. Основы создания пакетов описаны в Руководстве нового сопровождающего Debian и Справочнике разработчика Debian. [Источник 3]
Совсем простые, но малопригодные для серьёзного сопровождения пакеты можно создавать с помощью программы CheckInstall.
Установка с использованием командной строки
Установка из командной строки позволяет получить больше информации о процессе установки и позволяет гибко его настраивать, хотя и может показаться неудобной начинающему пользователю. Запустите терминал. Обновить данные о доступных в репозиториях программах можно командой:
По запросу введите пароль. Учтите, что при вводе в терминале пароль не отображается, ни звёздочками, ни кружками, никак. Это нормально. Для установки нужной программы введите команду:
Если нужно установить несколько программ, то их можно перечислить через пробел, например:
К сожалению не все программы входят в основные репозитории Ubuntu. Поэтому вам придется вручную подключать необходимые репозитории с нужными вам программами или пакетами, для этого вы можете воспользоваться статьей: Подключение репозитория. Или же попытаться найти необходимую информацию по установке, на официальном сайте программы.
Для поиска программы в списке доступных пакетов воспользуйтеcь командами:
Разновидности
Именование пакетов
Структура имени пакетов такова: имя-дополнение-версия_архитектура.deb
Создание deb пакетов
В этой статье мы рассмотрим как собрать deb пакет для своей программы без использования каких-либо сторонних инструментов. Мы не будем рассматривать подпись пакетов для репозиториев, потому что для каждого вида репозиториев команды будут отличаться.
Создание deb пакетов
Шаг 1. Подготовка
Давайте создадим для этого примера небольшую программу на Си. Она будет называться hellolosst и будет выводить на экран строку Hello from losst.ru в терминал при запуске. Сначала создайте папку hellolosst и перейдите в неё:
mkdir hellolosst
cd hellolosst
Затем поместите в неё файл с исходным кодом:
#include
int main() <
printf(«Hello from losst.ru\n»);
>
Для компиляции программы выполните такую команду:
Затем вы можете её выполнить:
Таким образом, теперь у нас есть программа, которую надо упаковать в deb пакет.
2. Создание манифеста
В каждом deb пакете содержаться не только файлы самой программы, но и файл манифеста, в котором описан пакет, его зависимости и параметры. Этот файл имеет название control и должен находится в папке DEBIAN. Для сборки пакета будем использовать папку package, чтобы файлы программы не путались с исходными файлами и те не попали в пакет. Создайте эти папку:
Прежде чем вы сможете создать этот файл надо узнать несколько вещей. Первым делом надо посмотреть размер файлов программы, поскольку в данном случае файл один, достаточно посмотреть его размер:
Если файлов несколько, то можно удалить исходники и посмотреть общий размер папки с файлами программы. Дальше надо понять от каких пакетов будет зависеть ваша программа. Для этого воспользуйтесь командой objdump:
В данном случае программе необходима только libc. Чтобы посмотреть в каком пакете она находится выполните:
Пакет называется libc6. Затем создайте файл манифеста со следующим содержимым:
Это минимальный набор параметров в файле манифеста. Вот их значение:
3. Расположение файлов
Манифест готов. Теперь в папке пакета надо создать структуру папок, аналог того, что есть в корневой файловой системе. В данном случае надо создать папку usr/bin и поместить туда исполняемый файл:
4. Скрипты установки
#!/bin/bash
echo «Hello from losst installed»
Разработчики Debian не рекомендуют использовать эти скрипты без крайней надобности, поскольку они дают вам полный контроль над системой пользователя и вы можете случайно что-то повредить. Обычно эти скрипты используются для того чтобы задавать пользователям вопросы и на основе этого генерировать конфигурационные файлы.
5. Сборка и проверка пакета
Осталось собрать настроенный пакет. Для этого используйте такую команду:
Теперь вы знаете как как собрать deb пакет. После завершения сборки можете установить его с помощью apt:
После этого исполняемый файл программы появится в /usr/bin, а сообщение из postinst будет выведено после установки.
Выводы
В этой небольшой статье мы рассмотрели как выполняется создание deb пакета с помощью инструмента dpkg-deb. Как видите, всё очень просто. Вам достаточно написать манифест и расположить файлы там, где они должны быть. Мы рассмотрели здесь только самые основы. На самом деле создание пакетов намного сложнее. Существует целый набор утилит debhelpers, которые используются на различных этапах сборки и установки deb пакетов, подробнее обо всём этом вы можете прочитать в официальной документации.
Воззрения кота Manual’а. Deb-пакеты. Часть 1. Пакеты
Изложение воззрений кота Manual’а на те аспекты работы с deb-пакетами, которые влияют на индивидуализацию системы. И первая их часть будет посвящена общим вопросам. В ней будет говориться о пакетах вообще и deb-пакетах в особенности. Читатель, знакомый с этими понятиями, может спокойно её пропустить.
Пакеты, зависимости, библиотеки
Пакеты — это своего рода программные кванты, на которые делится система или дистрибутив. Это могут быть и простые монофункциональные утилиты (например, строчный текстовый редактор ed или архиватор tar ), более или менее обширные наборы функционально связанных программ (скажем, coreutils) или составные части огромных программных комплексов (примером чему — рабочая среда Cinnamon, которая будет предметом специального рассмотрения).
Термин пакет (английское package) употребляется в двух смыслах: как авторский набор исходных текстов, созданный разработчиком программы, и как комплект скомпилированных из него исполняемых программ и всех их служебных файлов, собранный майнтайнерами дистрибутива или вообще третьими лицами. Пакеты в первом смысле называются исходниками или вообще «сырцами» (от английского Source), во втором — бинарниками. В этом manual’е речь пойдёт почти исключительно о пакетах во втором понимании этого термина.
Бинарные пакеты специфичны для семейств некогда родственных дистрибутивов, почему часто говорят о системах rpm based или deb based. Но даже если они собраны в одном формате (например, rpm или deb), бинарные пакеты из разных дистрибутивов далеко не всегда совместимы в рамках одной системы. Впрочем, к формату deb, который здесь рассматривается, это относится в наименьшей степени: например, пакеты для всех дистрибутивов семейства Ubuntu сохраняютпочти полную бинарную совместимость внутри него, а иногда — с пакетами прародительского Debian’а и его прямых клонов.
Ключевым для бинарных, или дистрибутивных, пакетов является понятие зависимостей. Суть его в том, что пакет packagename1 для сборки, установки и (или) функционирования требует наличия в системе пакета packagename2, тот, в свою очередь, может потребовать пакета packagename3, и так далее.
«Мягкие» зависимости данного пакета не критичны для его функционирования — удовлетворение их лишь добавляет ему дополнительные функции (например, печати и сканирования для офисных и графических приложений) или возможности (скажем, доступ к файлам данных определённых форматов для той же графики или мультимедиа).
В deb-формате бинарных пакетов предусмотрено более дробное разделение «мягких» зависимостей, но об этом подробнее будет говориться чуть позже. А пока замечу, что часто приходится учитывать и так называемые конфликтующие зависимости — то есть альтернативные по назначению пакеты, не способные ужиться в одной системе.
Понятие зависимостей пронизывает насквозь UNIX-совместимые системы, и особенно важно для свободных их представителей. Ибо традиционная модель разработки UNIX-программ (то, что задумчиво именуют UNIX Way) характеризуется ярко выраженным стремлением не множить сущности без крайней необходимости. Или, говоря попросту, не изобретать велосипеды. Ведь все программы, вне зависимости от их назначения, неизбежно должны выполнять некоторые однотипные действия, как то: открыть файл, записать его, вывести на экран его содержимое, и так далее. Сущность таких действий не меняется, что бы программа ни делала. И потому нет никакого смысла программировать такие манипуляции каждый раз заново.
Вот их, как правило, поддаваясь смертному греху лености, и не программируют «с нуля». А объединяют соответствующие директивы в отдельные программные комплексы, именуемые библиотеками (libraries). Сами по себе они к автономному исполнению не предназначены. Однако любая программа, при необходимости совершить одно из типовых действий, вызывает из такой библиотеки некий фрагмент кода, содержащий требуемую последовательность директив.
Однако главной системной библиотекой список не исчерпывается. В UNIX-подобных системах при создании пользовательских интерфейсов используются библиотеки свойств терминала (например, ncurces ) для консольных программ и библиотеки, описывающие процедуры отрисовки окон и управления ими — для графических программ системы X, библиотеки интерфейсных элементов и графических примитивов более высокого уровня (Motif, Qt, Gtk), библиотеки описания графических и мультимедийных форматов файлов и тому подобные «сборники». Иными словами, существует тенденция к вынесению в разделяемые библиотеки всех повторяющихся действий и элементов, какие только возможно.
Если библиотек, используемых в программах для консольного режима, не так много, они достаточно универсальны и легко поддаются учёту, то с библиотеками для обеспечения графического режима существенно сложнее. Даже простое перечисление их заняло бы немало места. Поэтому ограничусь упоминанием главных из них, на которых базируются рабочие среды (они же именуются десктопами, DE) и их штатные приложения.
Большая часть распространённых десктопов использует библиоотеки Gtk 3-й и, реже, 2-й верси. В их числе Cinnamon, LXDE, MATE, Xfce, Unity и, наконец, GNOME 3 (далее именуемый просто GNOME, поскольку вторая ветка этой среды вымерла соответственно. К ним же примыкает). Последний десктоп для своей работы требует также собственных библиотек GNOMElibc.
На библиотеке Qt основана среда KDE, которая также не живёт без собственных библиотек из набора KDELibs. Чистая Qt используется в настоящее время только в десктопе LXQt. Однако в будущем ожидается переход на эту библиотеку десктопа Budgie. Также на Qt основана среда Unity 8, в том числе и её десктопный вариант, который, правда, пока назвать работоспособным язык не поворачивается.
Надо заметить, что в последнее время возник и другой подход к разрешению запивсимостей: упаковка исполняемых модулей программ вместе со всеми необходимыми для их работы библиотеками в единый, самодостаточный пакет. Таковы системы Snap (изначально созданныая для Ubuntu, но ныне способная работать и в более иных дистрибутивах) и от рождения кросс-дистрибутивная система Flatpak. Однако ни та, ни другая всенародного признания пока не получили, так что речи о них в этом Manual’е не будет.
Формат deb-пакетов
Формат пакетов deb был разработан ещё в прошлом тысячелетии для дистрибутива Debian и унаследован от него Ubuntu, во многом предопределив успех последней. А вслед за ней — и удачливость многих её клонов. Почему deb-формату и следует уделить некоторое внимание.
Зависимости в терминах deb-пакетов имеют несколько градаций: обязательные ( depends ), рекомендуемые ( recommends ), предлагаемые ( suggests ), конфликтующие ( conflicts ). Первая градация — это обычные «жёсткие» зависимости, без удовлетворения которых пакет либо не будет работать, либо вообще не установится. С градацией последней тоже понятно — это, так сказать, анти-зависимости.
Ну а зависимости рекомендуемые и предлагаемые — это две разновидности «мягких» зависимостей. Разница между ними в том, что рекомендуемые пакеты обеспечивают «зависимому» пакету дополнительные функции (например, поддержку мыши в консольных приложениях), а пакеты предлагаемые предоставляют дополнительные возможности, вполне вероятно, полезные, но не жизненно необходимые (например, документацию, в том числе на не-английских языках).
То есть первая категория «мягких» зависимостей как бы более нужная, нежели вторая. Впрочем, таково субъективное мнение майнтайнера конкретного пакета — вполне возможно, что у применителя будет по этому поводу мнение более иное. И потому и пакетный менеджер apt, и его графическая «морда» Synaptic, устанавливающие зависимости автоматически, в в большинстве deb based дистрибутивов по умолчанию не делают этого ни для рекомендуемых, ни, тем более, для предлагаемых пакетов, а лишь выводят их список, дабы применитель сам принял решение по данному вопросу.
Кроме зависимостей, для пакетов deb-формата важно также понятие их приоритета. Оно отражает степень необходимости пакета для функционирования системы, например: обязательный ( required ), без которого работа системы невозможна, основной ( base ) и важный ( important ), также оказывающиеся практически необходимыми, стандартный, то есть имеющийся практически в любой полнофункциональной Linux-системе, дополнительный ( optional ) — тут уж степень важности каждый должен решать для себя.
Первый — самый обычный тарбалл исходных текстов авторского пакета, что подчеркивается словом orig в его имени: формат архива, имя и система нумерации версий также совпадают с таковыми авторского пакета. Файл packagename.dsc содержит в себе всю метаинформацию, необходимую для правильного построения из него бинарного deb-пакета. А packagename.diff.gz — это те изменения исходного кода, которые вносятся для адаптации пакета непосредственно к данному дистрибутиву. Если таких изменений не потребовалось (или если пакет писался именно для данного дистрибутива), он может и отсутствовать.
Статус пакетов
В системах пакетного менеджмента deb based дистрибутивов, в том числе и в Mint, пакеты объединяются в категории, секции и группы. Список категорий включает следующие пункты:
В секции пакеты группируются по назначению: программы для администрирования, базовые пакеты, текстовые редакторы, и так далее.
Каждый пакет в терминологии имеет основной статус, обозначаемый строчной литерой; в их число входят:
i (от install) — установленный пакет;
p (от purge) — пакет не установленный или деинсталлированный «вчистую» (то есть с удалением его конфигурационных файлов);
c (от clean) — пакет, деинсталлированный с сохранением конфигурационных файлов;
v (от virtual) — виртуальный пакет.
Кроме того, пакеты могут иметь один из следующих дополнительных статусов, хотя это и не обязательно:
Обращаю особое внимание на пакеты, имеющие статус A : они устанавливаются вместе со своими зависимостями и могут быть удалены только вместе с ними. Правда, как мы увидим дальше, статус установленного пакета может быть изменён, и тогда он станет доступным для индивидуального удаления.
Средства для работы с пакетами
Инструментарий для работы с пакетами можно разделить на пять групп:
Оболочки для установщиков пакетов выполняют те же самые функции, что и они сами, посредством как прямых команд (утилита gdebi ), так и средствами графического интерфейса. К числу последних принадлежат Gdebi (использующая Gtk), Gdebi-kde (для одноимённой среды), Qapt, основанная на библиотеке Qt. Сдежует заметить, что все эти оболочки не только отслеживают выполнение или нарушение зависимостей, но и предпринимают попытки их разрешения, более или менее успешные, в зависимости от обстоятельств.
Четвёртая группа — графические фронт-энды для менеджеров пакетов. Нынче она представлена программой Synaptic; её аналог для среды KDE, Muon, назвать вполне функциональной нельзя.
Что же касается пятой группы — это самые высокоуровневые программы, в которых прозрачно для применителя интегрированы функции поиска пакетов в Сети, подключения к содержащим их репозиториями и собственно пакетный менеджмент. Название её заимствовано от Центра приложений Ubuntu — первого представителя этой группы. Хотя в некоторых случаях программы этой группы могут оказаться полезными, автору этих строк они представляются избыточными, и речи о них в данном Manual’е не будет. Остальные же инструменты работы с пакетами будут рассмотрены в его следующих частях.
1 комментарий к “Воззрения кота Manual’а. Deb-пакеты. Часть 1. Пакеты”
Оставьте комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Введение
Несмотря на то что большинство пакетов создается с использованием debhelper, понимание того как устроен deb-пакет «изнутри» даст возможность разобраться зачем нужна та или иная утилита dh_ или что делать когда возникает задача создать «нестандартный» src-пакет итд. Лишние знания, как известно не отягощают голову, а, напротив, облегчают ей работу когда перед ней наконец появляется задача, требующая решения 
Что представляет собой deb-пакет?
Deb-пакет это обычный архив файлов, содержащий файлы, предназначенные для установки в систему, а так же некоторые служебные файлы, необходимые для того чтобы эту установку сделать гибкой. При помощи программы ar упаковано в один файл:
Архив control.tar.gz, содержащий скрипты, написанные майнтенером пакета, использующиеся при установке/удалении пакета, а так же другие служебные файлы;
Архив data.tar.gz, содержащий двоичные файлы программы, ради которой создан пакет;
Поскольку содержимое пакета может в будущем измениться (будет новый номер версии в debian-binary), то собирать deb-пакет при помощи программ tar, gzip, ar не рекомендуется и этот вариант в статье рассматриваться не будет.
Файлы и каталоги, предназначенные для установки в систему. Их расположение в архиве соответствует положению их в файловой системе если считать от корня. Например файл usr/share/doc/package/copyright в deb-архиве после установки будет находиться в /usr/share/doc/package/copyright (все они будут упакованы в архив data.tar.gz);
Каталог DEBIAN/, содержащий служебную информацию о пакете (о ней пойдет речь ниже). Содержимое этого каталога при сборке будет упаковано в архив control.tar.gz;
Низкоуровневые функции работы с deb-пакетом
Программа dpkg
Представляет наиболее низкоуровневый интерфейс для создания/установки/распаковки пакетов.
при этом из каталог Directory будет упакован в пакет.
То есть все что нам нужно чтобы создать пакет для Debian, это сложить файлы в нужные директории и упаковать. Фактически это почти тоже самое что и простой архив tgz дистрибутива slackware, только информационные файлы располагаются в каталоге с другим именем и видов этих файлов несколько больше.
Ну а теперь, когда мы уяснили базовое устройство пакета, можем перейти к описанию того что должно или может находиться внутри каталога DEBIAN/.
Обязательное содержимое DEBIAN/
Файл control
и некоторые другие параметры.
Короткое описание содержимого этого файла на русском языке Вы можете найти здесь, а полное описание на английском языке в Debian-policy. Смотрите так же man deb-control.
Необходимо отметить: в src-пакетах как правило лежит файл debian/control, который является лишь шаблоном для того файла contol, который будет упакован в deb-пакет. Скрипты сборки пакета добавят несколько полей в этот шаблон, вычислят зависимости от библиотек, проставят версию пакета (взяв ее из changelog), разобьют общий control нескольких пакетов на несколько control-файлов, если из одного src-пакета производится сборка нескольких deb-пакетов.
Опциональное содержимое DEBIAN/
Файл md5sums
Содержит md5 хеши для всех файлов кроме файлов находящихся в каталоге DEBIAN/. Данный файл необязателен для deb-пакета, однако программы верификации пакетов считают пакеты, несодержащие этот файл ошибочными. Может использоваться некоторыми программами администрирования системы для верификации изменений в файловой системе.
Скрипты для установки/удаления пакета
Пакет может содержать несколько скриптов (или программ), которые будут вызываться при установке/удалении пакета. Эти скрипты позволяют майнтенеру выполнять некоторые действия при установке/удалении. Например этими скриптами могут создаваться/удаляться каталоги в которых программа будет хранить свои временные данные, может производиться добавление/удаление программы в меню вашего оконного менеджера, первичное конфигурирование программы и так далее.
Соответственно порядок вызова скриптов и опции их вызова может быть разный. Скрипты могут вызываться со следующими параметрами (полный перечень можно найти в Debian-policy):
Параметр
Доп-параметры
Описание
preinst
Вызывается перед распаковкой пакета. Номер версии указывает на пакет, который стоял ранее, но был удален без ключа —purge, то есть конфигурационные файлы сохранены. С данным параметром скрипт вызывается если в системе пакет не установлен.
Вызывается перед распаковкой пакета. Номер версии указывает на пакет, который стоял ранее. Выполняется upgrade или downgrade для пакета. Зная текущую версию пакета и сравнив её с передаваемым здесь значением мы можем определить что происходит upgrade или downgrade
Вызывается если preinst upgrade вызванное для нового пакета завершилось неудачей. Номер версии соответствует номеру версии нового пакета, который пытались установить. Таким вызовом установленный пакет информируется о том что его попытались неудачно проапгрейдить.
postinst
Вызывается после распаковки пакета. Номер версии содержит версию пакета корректно сконфигурированного ранее. То есть того для которого данный вызов завершился без ошибки. По номеру версии скрипт конфигурации может принять решение о том каким образом необходимо производить апгрейд конфигурационных файлов программы
Вызывается системой Debconf после переконфигурации пакета. Выполняет все необходимые действия по переконфигурации.
Вызывается если preinstall upgrade нового пакета завершился неудачей. Новый пакет не устанавливается, а старый при этом может провести собственную переконфигурацию для того чтобы сохранить работоспособность.
prerm
Вызывается перед удалением пакета.
Вызывается перед удалением пакета при его апгрейде. Номер версии указывает на версию устанавливаемого пакета.
Вызывается для устанавливаемого пакета, если prerm upgrade удаляемого пакета завершился с кодом ошибки. Номер версии указывает на удаляемый пакет
postrm
Вызывается после удаления пакета
Вызывается после удаления пакета при его апгрейде. Номер версии указывает на новый пакет.
Вызывается после удаления пакета при его апгрейде. Вызывается в случае если postrm upgrade вернул код ошибки. Номер версии указывает на удаляемый пакет. Вызов скрипта происходит во вновь устанавливаемом пакете.
Вызывается если preinst install вернул код ошибки. Номер версии соответствует номеру версии передаваемому preinst install
config
Вызывается во время предварительной настройки пакета из dpkg-preconfigure. Этот вызов проходит во время установки/апгрейда пакета. Номер версии указывает на версию установленного на данный момент пакета.
* Необязательный параметр
Файл templates
Если используется возможность конфигурации/реконфигурации пакета в системе Debconf (скрипт config), то этот файл содержит шаблоны диалогов с пользователем.
Файл conffiles
Содержит перечень файлов пакета, которые являются конфигурационными. По одному файлу на одну строку. Эти файлы при апгрейдах пакета заменяться не будут (или же будут задаваться вопросы с предложением о замене). Подробнее о содержимом см. man debconf-devel
Утилиты для работы/генерации содержимого DEBIAN/
Утилита dpkg-gencontrol
Осуществляет генерацию файла control на базе шаблона этого файла, составляемого майнтенером, а так же дополнительных параметров, передаваемых из командной строки. В частности, устанавливает номер версии пакета, архитектуру итп. Номер версии обычно берется из файла changelog, однако иногда бывает необходимо из одного src-пакета собрать несколько deb-пакетов с разными номерами версий. Опция -v поможет Вам в этом.
Утилита dpkg-shlibdeps
Вычисляет зависимости для исполняемых файлов и библиотек. Майнтенер обычно указывает Build-зависимости (зависимости сборки), а Depend-зависимости (зависимости необходимые для работы) вычисляются с помощью этой (или подобных) утилит. Такой подход дает возможность не привлекать майнтенера при смене имен библиотек от которых зависит пакет.
Утилита dpkg-parsechangelog
Позволяет извлекать из changelog-файла некоторые параметры, вроде номера версии, координат и имени майнтенера итп. Результаты работы этой утилиты могут использоваться как входные параметры для утилит вроде dpkg-gencontrol.
Утилита dpkg-architecture
Позволяет извлекать информацию (манипулировать ей) об архитектуре системы для которой собирается пакет или на которой собирается пакет. Выходные данные так же могут использоваться для использования в других утилитах. Например при генерации файла control утилитой dpkg-gencontrol.
Проверка соответствия пакета современным требованиям Debian
После того как пакет создан, можно получить информацию о его содержимом с помощью вышеупомянутой утилиты dpkg.
После этих двух проверок (все файлы на месте, информация в финальном control корректна), можно запустить одну из двух проверки пакета на соответствие текущему полиси.
покажет подробную информацию о проблемах в пакете.