Перший спосіб. який напрошується сам собою це поставити який-небудь VirtualBox / Xen / OpenVZ / KVM / VMware, поставити в нього операційну систему і зайнятися власне складанням пакета. Якщо потрібно щось автоматизувати, то доведеться дійсно попотіти.
Третій спосіб. У репозиторії openSUSE Tools є пакет build. який створює оточення в chroot і збирає пакет. Напевно єдиний його недолік полягає в тому, що для створення chroot-оточення потрібно мати на локальному диску пакети необхідного дистрибутива. Це не приємно, але пережити можна.
Отже, нам знадобиться 64-х бітна машина (на ній можна збирати пакети і під ix86 і x86_64). Підключаємо репозиторій і ставимо пакет build. Після цього робимо локальну копію репозиторіїв для потрібних дистрибутивів (іноді досить просто DVD диска дистрибутива). Мінус звичайно великий, але якщо достатньо місця, то потім вже непомітно. Звичайно доведеться налаштовувати синхронізацію з репозиторіями. Краще розвести різні архітектури в різні каталоги, так буде простіше.
У пакеті build в каталозі / usr / lib / build / configs зберігаються настройки для різних дистрибутивів. За замовчуванням там є Debian і всілякі SUSE. Сценарії для інших дистрибутивів, а це Fedora, Mandriva, Ubuntu включаючи різні версії можливо отримати через систему контролю версій osc. Але так як для цього доведеться описувати взагалі всю OBS, то ви можете просто завантажити файли конфігурації з мого архіву. Їх необхідно буде покласти в каталог / usr / lib / build / configs.
Ця команда з пакета build витягне весь вміст исходника в поточний каталог. Власне якщо у нас є вихідні, то їх достатньо покласти в поточний каталог. Після цього віддаємо команду (з-під користувача root):
Якщо нам потрібно буде зібрати 32-х бітний пакет, то попередня команда прийме наступний вигляд:
Опція --rpms може підчіплювати кілька каталогів. Для цього шляху потрібно розділити символом ":", наприклад:
Збирати deb-пакети я не пробував, але швидше за все відмінностей не багато. Подібний спосіб дуже зручний, коли хочеться збирати пакети у себе на машині, а не робити це десь там. В цьому випадку набагато зручніше відстежити вдалу або невдалу збірку пакета, написати скрипти для обробки результатів, викладення в репозиторії, поставити збірку в свою власну систему continuous integration. Єдиний недолік це наявність дуже великого вільного простору під пакети дистрибутива.
Сторінка 1 з 1 1
Пасиб за статтю - у Мандріва є свій chroot - але боляче складний і на perl 🙂 Я сам поки використовую виртуалки з мінімальною установкою, які скриптом копіюються, в них по ssh виконується вхід і передається сурс. Єдиний плюс віртуалок - це ріпи не так на диску, а в інеті можна використовувати.
Tigro.
iurt кажись називається.
Ось мені було б цікавіше дізнатися спосіб збірки
РКК під Федору.
Про моск і РКК-девтоолся я знаю а ще що?
P.S. А то з сабжем Ви можете дійти і до збірки msi 🙂
Tigro.
Тигро, а ти сам збираєш цим build'ом?
Я до сих пір збирала або в Моке, або в контейнері OVZ (іноді теж в mock)
Мені потрібно, мабуть, щось навіть майже промислове, але локальне OBS все-таки відлякує своєю монструозність
Tigro.
Так, у мене на Fedora зараз так Yachat збирається під Mandriva і openSUSE. Build в цьому дуже добре допоміг.
По хорошому для складання пакетів під найпопулярніші дистриб потрібен якийсь Debian SID (бо там распоследний rpm). Там можна використовувати pbuilder (для deb), mock (для rpm) і build для Mandriva, SUSE.
Є ще одна альтернатива:
1. збирати portable (дистрибутиви-незалежні) бінарники
2. упаковувати їх у rpm
3. з rpm робити deb за допомогою alien'a
Перевага в тому, що компіляцію доводиться виконувати тільки 2 рази (один раз для i386, інший - для x86_64). Зате такий rpm або deb пакет ставиться практично на будь-який десятеро. Можна ще і в tar.gz упакувати для всіх інших. Крім того, не потрібно мати диск кожного дистрибутива - потрібен тільки debian etch, але взагалі debootstrap благополучно може затягнути з инета по-мінімуму тільки необхідне.
мінуси:
- Більший розмір пакета, тому що доводиться упаковувати включати залежні бібліотеки.
- Більше метушні зі складанням, знову ж тому доводиться збирати залежні ліби. Я під цю справу заточую скрипт, щоб при виході чергової версії не робити все заново.
Зате у бінарників є великий плюс - наприклад якщо це ktechlab або quanta + на kde4 дистриб (треба спробувати в загальному) 🙂
Збірка DEB-пакетів, до речі, сильно відрізняється від RPM. А для Ubuntu ви забули згадати LaunchPad з його build-демонами і PPA =)
Tigro.
Ні не забув, так як я описував build. А launchpad вміє збирати тільки під Ubuntu. Ну і в рамках build збірка deb-схожа на збірку rpm (коли вже все зроблено). Потрібно тільки знати як створювати і збирати пакети, власне про що я і писав в першому абзаці.
А ссилочку на архів з конфіга не працює. 404, говорить 🙁
Tigro.
Так, потералось після останньої пожежі. Треба буде відновити.