Як і навіщо створювати пакети -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. (Див. Пакети символів налагодження ) -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

Підвищення - складний приклад, розглянемо спочатку більш простий.

В точному, 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пакунки.

Крім того, точно містить старішу версію бібліотеки, 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 . Існує також прискорене налаштування метапакетів яке втягується у пакет, що перетворюється, як залежність.

Дивлячись на libhangul , окрім динамічного пакету бібліотеки libhangul1та пакета для розробки libhangul-dev, є пакет libhangul-data. Цей пакет містить додаткові дані, необхідні бібліотеці. Навіть якщо у вас є кілька версій бібліотеки, вони можуть поділитися -dataпакетом. Також пакет не залежить від архітектури. Програмне забезпечення, що містить велику кількість незалежних від архітектури даних, розділено на незалежні від архітектури та незалежні від архітектури пакети, щоб заощадити місце на сайтах розповсюдження. Ще один суфікс з подібним значенням-common .

Правила упаковки Ubuntu та Debian дуже схожі, тому матеріал про створення пакетів Debian також стосується Ubuntu. Насправді, ви можете мати один і той же вихідний пакет для Debian і Ubuntu; єдине, що робить пакети Debian і Ubuntu різними - це їх компілювання проти різних версій бібліотеки, і це не більше ніж різниця між різними випусками Ubuntu. Мати документації Debian розробник під рукою, особливо Debian Policy Manual і в Довідник розробника ; див . Посібник з нового технічного обслуговування для ознайомлення. Ігноруйте частини про роботу з проектом Debian і так далі, просто прочитайте частини про створення пакету.dh_make це хороший спосіб розпочати роботу з дебютним пакетом (вам потрібно вибрати "Бібліотека").

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.