Нечасто, але трапляється, в житті системного адміністратора такий момент, коли для роботи системи потрібно зібрати пакет з більш новою версією софта або накласти патч на систему.
Або взагалі створити пакет зі своєю програмою, щоб штатними, для операційної системи, методами встановлювати і контролювати процес оновлення програми. Хоча це вже не зовсім турбота системного адміністратора.
Отже, у нас є бажання зібрати пакет і зробити це правильно.
Я не буду розповідати як зробити пакет з нуля, я хочу розповісти саме про те, як його збирати. Передбачається, що пакет вже є з усім необхідним.
Що нам знадобиться
Як робити не варто
Як видно з назви: все що описано нижче, робити не варто, але якщо хочеться, то можна і так обійтися.
Не знаю як у вас, а в мене моя робоча машина наполовину складається з пакетів, які йдуть з бекпортов, ppa і інших сторонніх репозиторіїв.
Що з цього випливає? З цього випливає, що можуть бути помилки пов'язані з неправильною лінковкою бібліотек (наприклад часта ситуація, коли не просто неправильно лінкуются скомпілірований файл, а дещо змінюється логіка роботи самої системи збирання програми в залежності від наявних версій). Але якщо ви для себе збираєте, то цей спосіб цілком підійде.
Найбільш часто зустрічається у мене спосіб збірки - взяти офіційний пакет з більш старшої версії і зібрати його для свого дистрибутива. Цей процес називається бекпортірованіем.
Давайте розглянемо наприклад пакетування supervisor, в wheezy використовується 3.0a8, а нам потрібна найсвіжіша версія 3.0. У sid на поточний момент є тільки 3.0b2.
Йдемо на сторінку з пакетом і викачуємо исходник пакета (колонка справа, dsc файл):
Тепер нам потрібно взяти архів з останньою версією supervisor:
Далі нам необхідно оновити версію пакету:
А тепер можна приступати до процедури складання (ось саме це і неправильно робити з причин описаним вище):
Після складання в директорії з'явиться deb файл, який можна коректно встановити:
Як варто робити
В силу зазначених вище причин, необхідно використовувати підготовлене оточення, яке буде містити в собі мінімальний набір пакетів які відповідають тому оточенню, в якому збираються пакети для дистрибутива.
Зрозуміло, що нічого винаходити для цього не потрібно і все вже є готове і мільйони разів протестована: (c) debootstrap.
Однак debootstrap просто викачує і розпаковує оточення, а щоб там щось зібрати потрібно зробити туди chroot, купу всього примонтировать, загалом, теж багато одноманітної і нудної роботи.
Тому розробники дистрибутива зробили pbuilder (є ще sbuild, який власне і використовується на складальних серверах, про те чому pbuilder, а не sbuild почитати можна тут), який дозволяє збирати пакети в чистих середовищах.
Pbuilder дуже добре Кастомізіруйте через файлик pbuilderrc, але і тут розробники пожвавішали і зробили pbuilder-dist, який бере на себе турботу по підтримці багатоплатформності.
На жаль з коробки він є тільки в Ubuntu, в пакеті ubuntu-dev-tools. Але для Debian його можна взяти з PPA.
Користуватися ним надзвичайно просто:
І після закінчення процедури складання готовий пакет з'явиться в
А що щодо кастомізації, запитаєте ви? Нічого не змінилося, pbuilder все також підхоплює свою конфігурацію з, наприклад,
Це рішення підкуповує мене своєю простотою і зручністю.
Виникає резонне питання, а що далі з пакетами робити.
налаштовуємо репозиторій
Як я вже неодноразово скаржився в блозі, в інтернеті мільярди інструкцій на всі випадки життя, але серед них немає жодної нормальної. Вони або неповні, або не працюють, або працюють, але не так, як потрібно (або правильно).
Така ж фігня зі створенням репозиторіїв. Велика частина інструкцій пропонує використовувати щось типу apt-ftparchive, а потім руками підписувати репозиторій (якщо взагалі це пропонують робити). Напевно адже розробники подумали як автоматизувати цю задачу і є готові хороші інструменти.
Таким інструментом я можу назвати reprepro.
Його використовує багато хто, наприклад офіційний репозиторій nginx створений за допомогою reprepro.
Однак у нього є мінус - зайві директорії в корені архіву, тому я намагаюся відокремлювати робочу директорію від доступного з мережі сховища.
Я також не можу сказати, що reprepro працює ідеально, іноді у нього бувають абсолютно незрозумілі помилки, які вимагають додавання не надто очевидних опцій, але на тлі інших, він працює дуже добре.
Я не хочу розповідати як генерувати GPG ключ і як з ним звертатися, за мене це відмінно зробив @cancel.
Створимо директорію де буде працювати reprepro:
В директорії conf буде два файли:
- options відповідає за опції reprepro
- distributions відповідає за настройки репозиторіїв