RedHat: чи можна встановлювати пакети в своєрідному макетному середовищі для створення RPM

10

Чи є інструмент, який дозволяє встановити залежності RPM .spec в ізольоване середовище? Я не буду встановлювати такі залежності глобально в системі, і я не в змозі це зробити, оскільки не маю права доступу до root.

Причина

Я хочу створити пакет A, який залежить від нової версії B (яка не може бути встановлена ​​глобально в системі).

Я хотів би побудувати нову версію B , і нехай інструмент збірки встановити B «S -develйого в ізольоване середовище , щоб забезпечити всі необхідні файли для збірки A .

Рішення

  • Чи є інструменти для цього?
  • Якщо ні, то про що я повинен подбати, коли намагаюся це зробити chroot?
  • Це було б поганою практикою?
linux  chroot  rhel6  rpm 
— пробувати-нарешті
джерело

Відповіді:

8

Так, інструмент викликається mockі знаходиться в EPEL.

Типове використання:

rpmbuild -bs mypackage.spec
mock -r epel-6-x86_64 mypackage-0.1-1.src.rpm

Це насправді кращий спосіб побудови RPM, саме тому, що він ізолює процес від системи, щоб несподівані залежності не потрапляли.

Ви можете модифікувати файли, /etc/mockщоб вони містили ваші власні пакети, приватне репо, тощо, або перевіряти документи на інформацію про те, як додати пакунки до mockсередовища chroot вручну.

Зауважте, що користувачів слід додати до mockгрупи, дозволеної до використання mock.

Не випадково kojiсервер збирання, який Red Hat використовує дзвінки, mockстворює кожен окремий пакет. Якщо вам доведеться постійно збирати багато пакетів, можливо, варто розібратися з налаштуванням kojiсервера збірки.

— Майкл Хемптон
джерело
Дякую Майклу. Це звучить дуже добре, я радий, що моє запитання було не таким нерозумним, як я думав. ;)
— пробуй-нарешті
3

Я думаю, що намагатися створити пакети на хостах виробництва - це погана практика, а спроба зробити це без привілеїв root є складнішою, ніж створення власних машин побудови. Я зазвичай роблю наступне.

  1. Встановіть VirtualBox або подібний інструмент на робочий стіл / ноутбук
  2. Створіть 32/64 ВМ ОС, яку ви використовуєте у виробництві
  3. Встановіть зазвичай інструменти макетування, rpmbuild тощо
  4. Створіть RPM для пакета та будь-які додаткові відбитки для обох арк у ваших віртуальних машинах
  5. Після тестування натисніть RPM у внутрішнє репо для розподілу на ваші сервери
  6. Перевірте ще раз, щоб переконатися, що належні залежності підтягуються
  7. Відпустіть через управління конфігурацією.
— Рамін
джерело
Це спрацює. Як це краще, ніж використовувати макет? Я б подумав, що знущатися буде простіше, але я підозрюю, що в будь-якому випадку відбувається те саме.
— emory
У мене немає проблем з макетом, і я вважаю, що майже всі документи "як зробити rpm" встановили це. Однак без кореневого доступу я не впевнений, як ОП збирає додавати свій обліковий запис до групи макетів, встановлювати макет тощо. Також чисті віртуальні віртуальні машини допомагають уникнути випадкових залежностей від ненавмисного додавання до пакетів.
— Рамін
Відмінний момент. Я не зміг цього врахувати. Зважаючи на це, я думаю, що це правильна відповідь.
— Еморі
@emory на основі ваших відгуків я уточнив, чому я думаю, що побудувати VM - це краще рішення загалом, на який я думаю, що дає кращу відповідь. Дякую за те, що ви мене подали. :-)
— Рамін
@Ramin в моїй ситуації (на роботі) Я лише користувач . Система є спеціалізованою системою збірки і добре, якщо всі розробники на цьому хості мали б привілеї root, це поле не завантажуватиметься після 1 тижня. ;) Тож використання такого інструменту як Mock - це саме правильна річ! Налаштування VM також є хорошою ідеєю, якщо вона може бути добре автоматизована. Я думаю, що Вагрант (я ще не перевіряв його) - це лише правильний інструмент для цього.
— try-catch-нарешті
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.