Как и зачем создавать пакеты -dbg, -dev, -doc?


15

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

Я заметил, что такие пакеты, как Boost, предоставляют

[...]
libboost-dbg
libboost-dev
libboost-doc
[...]
libboost-all-dev
[...]

но ничего, что идет по имени boostили libboost.

  • Какова идея этого?
  • Каковы цели -dbg, -devи -docпакеты?
  • Есть ли инструкции о том, как написать файлы сборки для этих пакетов?

Ответы:


13

Идея и цель

Основная причина разделения этих различных пакетов связана с дисковым пространством и скоростью загрузки. В частности, это большая проблема для зеркального пространства, поскольку это означает распространение нескольких копий данных. Делая foo-common, foo-dataили foo-docпакетыArchitecture: all , мы только сохранить одну копию данных в архиве вместо того , она скопирована с каждой архитектуры (например , i386, amd64, т.д ...). Символы отладки не нужны большинству пользователей, и в итоге загрузка пакета занимает больше времени.

Для пакетов в официальных архивах Ubuntu фактически нет причин создавать -dbgпакеты вручную. Машины сборки автоматически -dbgsymудаляют символы отладки и помещают их в пакеты, размещенные на ddebs.ubuntu.com. (См .: Debug Symbol Packages ). -dbgСуществующие пакеты обычно просто переносятся из Debian.

инструкции

Что касается реализации, взгляните на этот вопрос:

Вкратце, debian/controlдля каждого пакета необходимо создать новые строфы . Затем debian/foo-*.installфайлы должны быть созданы. Это позволит dh_installпоместить правильное содержимое в нужные пакеты.

Для foo.installосновного двоичного пакета может выглядеть так:

usr/bin/
usr/lib/

foo-common.install, foo-data.install, foo-doc.installИли что угодно:

/usr/share/doc/
/usr/share/icons/
/usr/share/foo/
/usr/share/locale/

И для foo-dev:

/usr/include/
/usr/lib/pkgconfig
/usr/lib/*.so

Создание foo-dbgпакета требует редактирования, так debian/rulesкак обычно dh_stripудаляются символы отладки. Итак, нам нужно переопределить это поведение:

.PHONY: override_dh_strip
override_dh_strip:
        dh_strip --dbg-package=foo-dbg

12

Boost - сложный пример, давайте сначала посмотрим на более простой.

В частности, пакет исходного кода openssl предоставляет 5 бинарных пакетов:

  • libssl1.0.0содержит динамическую библиотеку OpenSSL, версия 1.0.0. Вот для чего нужно запускать программы, связанные с этой библиотекой. Имя пакета содержит номер версии, поскольку у вас могут быть одновременно установлены другие версии библиотеки, если у вас есть другие программы, связанные с другой версией, которая не совместима с 1.0.0 в двоичном формате.
  • opensslсодержит инструменты командной строки, которые используют библиотеку OpenSSL. Даже если у вас есть несколько версий библиотеки, вам не нужно несколько версий этих инструментов: есть только одна /usr/bin/opensslи связанные инструменты, данные и документация.
  • libssl-devсодержит файлы, которые вам нужны, если вы хотите скомпилировать программу, которая ссылается на OpenSSL. Есть заголовочные файлы C ( *.h), библиотеки для связывания ( *.a, *.so) и несколько разных файлов.
  • libssl-docсодержит документацию для библиотеки OpenSSL. Вам нужен только этот пакет, если вы собираетесь писать программы, которые используют библиотеку.
  • libssl1.0.0-dbgсодержит символы отладки. Это полезно только для людей, которые отлаживают библиотеку OpenSSL или программы, которые ее используют. Ответ andrewsomething содержит больше информации об этих -dbgпакетах.

Кроме того, в Precision содержится более старая версия библиотеки, libssl0.9.8поскольку существуют программы, которые по-прежнему связаны со старой версией.

Другие пакеты, которые вы можете увидеть, являются привязками для языков, отличных от C. OpenSSL не поставляется ни с одним (есть привязки к OpenSSL для других языков, но они не из того же источника). Примером является sqlite3 , который поставляется с привязками TCL .

Основная причина такого разделения пакетов заключается в том, что разные пакеты имеют разную целевую аудиторию. Система, в которой никто ничего не компилирует, нуждается только в основном libпакете и, возможно, в инструментах командной строки; при необходимости они будут установлены автоматически из зависимостей. Если кто-то хочет скомпилировать программу, которая использует библиотеку, ему нужен -devпакет. Если кто-то хочет написать программу, которая использует библиотеку, ему нужен -docпакет.

Так что насчет Boost? Он имеет ту же структуру, но поскольку Boost - огромная библиотека, он разбит на множество небольших пакетов: libboost-*1.46.1и libboost-*1.46-dev. Точнее, есть только одна версия Boost, 1.46 , но у oneiric было и 1.42, и 1.46 . Существует также мета - пакет boost-defaults, который вытягивает версионный пакет как зависимость.

Глядя на libhangul , кроме пакета динамической библиотеки и пакета libhangul1разработки libhangul-dev, есть пакет libhangul-data. Этот пакет содержит дополнительные данные, необходимые для библиотеки. Даже если у вас есть несколько версий библиотеки, они могут поделиться -dataпакетом. Также пакет не зависит от архитектуры. Программное обеспечение, которое содержит большое количество архитектурно-независимых данных, разбивается на архитектурно-независимые и архитектурно-независимые пакеты для экономии места на сайтах распространения. Другой суффикс с подобным значением является -common.

Правила упаковки Ubuntu и Debian очень похожи, поэтому материал о создании пакетов Debian также применим к Ubuntu. Фактически, вы можете иметь один и тот же исходный пакет для Debian и Ubuntu; единственное, что отличает пакеты Debian и Ubuntu, это компилирование их для разных версий библиотеки, и это не более чем различие между различными выпусками Ubuntu. Имейте под рукой документацию для разработчиков Debian , особенно руководство по политике Debian и справочник разработчика ; см . Руководство нового сопровождающего для ознакомления. Игнорируйте части о работе с проектом Debian и так далее, просто прочитайте части о создании пакета.dh_make хороший способ начать работу с пакетом deb (вам нужно выбрать «Library»).

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.