Изоляция среды сборки и разделение файловой системы

хорошо, поэтому после попытки преследовать зависимости для различных частей программного обеспечения в n-й раз и тиражирования работы, которую различные люди делают для всех различных дистрибутивов linux, я хотел бы знать, есть ли лучший способ объединения различных частей программного обеспечения в один .rpm или .deb файл для более удобного распространения.

моя текущая настройка для этого-монстр Франкенштейна различных инструментов, но в основном Vagrant и libguestfs, построенный из исходного кода Fedora, потому что ни один из дистрибутивов фактически не отправляет его с virt-diff. Вот шаги, которые я в настоящее время следую:

  1. раскрутите базовую ОС, используя либо бродячую коробку, либо создайте ее из живых компакт-дисков.
  2. экспорт .vmdk и называть это base-image.
  3. разверните точную копию предыдущего изображения и перейдите в город: используйте менеджер пакетов, или какие-то другие средства, чтобы загрузить, скомпилировать и установить все части, которые мне нужны. Еще раз экспортируйте .vmdk и назовите это non-base-image.
  4. сделайте оба базовых образа доступными для гостевой ОС Fedora с libguestfs.
  5. использовать virt-diff чтобы отличить два изображения и сбросить эти данные в файл под названием diff.
  6. запустите несколько скриптов ruby для массажа diff в другой формат, который содержит необходимую мне информацию, и ни одно дерьмо мне не нравится в /var.
  7. запустить другой скрипт для создания скрипта для guestfish с кучей copy-out команды.
  8. запустить guestfish сценарий.
  9. запустите другой скрипт для восстановления символических ссылок из diff, потому что guestfish не могу.
  10. превратите полученную структуру папок в a .деб ор .RPM файл и отправить его.

я хотел бы знать, если есть лучший способ сделать это. Можно было бы подумать, что будет, но я не понял.

7
build debian isolation linux rpm

5 ответов

Я бы определенно рассмотрел что-то вроде:

A)

  • список yum (выберите свои пакеты/зависимости, что угодно)
  • используйте yumdownloader в предыдущем списке (или используйте уже загруженные ПКГ)
  • createrepo
  • корабль на носителе со сценарием установки, который добавляет РЕПО cd в repolist и т. д.

или B)

первые два шага, как указано выше, затем упакуйте rpms в архив создайте пакет, который содержит все вышеперечисленное и запускает фактическую установку rpms (по линиям rpm-Uvh /tmp/repo/*) в качестве позднего скрипта (на этапе очистки, возможно). Не знаю, можно ли это сделать, избегая блокировок в базе данных rpm.

3

проблема в первую очередь в том, что ваши клиенты установили все стандартные пакеты дистрибутива, необходимые для запуска вашего пакета?

Если это так, то я считаю, что самым простым решением было бы использовать инфраструктуру yum и apt, чтобы эти инструменты отслеживали и устанавливали необходимые предварительные пакеты.

Если вы предоставляете собственный репозиторий yum/apt с полными спецификациями pre-req (тяжелая работа, которую вы по-видимому, уже завершено). Затем стандартный инструмент установки системы позаботится об остальном. См. ссылку ниже для получения дополнительной информации о создании личного репозитория для yum / apt.

для оффлайн клиентов, вы можете поставить средства массовой информации с вашим программным обеспечением, и зеркала или зеркала подмножество-вышестоящего дистрибутива и инструкции по их добавлению в конфигурации Yum/apt config.

Юм создание репозитория Yum in руководство по развертыванию Fedora

Apt Как Настроить Репозиторий Debian на Вики Debian

1

Я думаю, вы достигли точки сложности-действительно монстра Франкенштейна - где вы должны перестать бояться делать правильные пакеты с зависимостями. Мы сделали это в моей предыдущей работе - у нас был набор готовых пакетов - и это было очень легко и просто, в том числе:

  • перед/после установки скриптов
  • скрипты удалить
  • зависимости

нам никогда не приходилось делать то, что вы только что описали. И для клиент, установка даже набора пакетов была очень простой!

вы можете следовать справочному руководству как построить пакет RPM для получения дополнительной информации.

EDIT: Если вам нужен один установочный пакет, создайте этот master packge, который будет содержать все остальные пакеты (с правильно установленными зависимостями) и установил их в сценарий после установки (и удалил их в сценарии удаления).

1

есть в основном 3 шага, чтобы сделать пакет со всеми зависимостями (пусть это будет A, B & C).

A. соберите необходимые файлы.
Существует множество способов сбора файлов основного программного обеспечения и его зависимостей. Чтобы получить все зависимости и для безошибочного запуска, вам нужно использовать базовую ОС (i.e живая система)
1. Использование AppDirAssistant
Это приложение используется www.portablelinuxapps.org чтобы создать портативный каталог приложений. Они сканируют и следят за файлами, к которым обращаются приложение для поиска требуется.
2. Использование chroot & overlayfs
В этом методе вам не нужно загружаться в live cd вместо chroot в него.
а. крепление .iso @ / cdrom и
б. монтирования файловой системы(файловой системы.squashfs) @ другое место, скажем @ /tmp/union / root
c. Bind mount /proc @ /tmp/union/root / proc
d. Наложение на него
mount -t overlayfs overlayfs /tmp/union/root -o lowerdir=/tmp/union/root,upperdir=/tmp/union/rw
e. Chroot
chroot /tmp/union/root

теперь вы можете установить пакеты с помощью apt-get или другой метод (только от chrooted terminal). Все измененные файлы сохраняются @ /tmp/union/rw. Возьмите оттуда файлы.
3. Использование собранных вручную пакетов
Используйте диспетчер пакетов для сбора зависимостей. Например apt-get install package --print-uris будет печатать uris загрузки для пакетов dep. Используя этот uris, загрузите пакеты и извлеките все (dpkg -x 1.deb ./extracted).

Б. чистые мусорные файлы
После сбора файлов удалите ненужные файлы

C. Pack files
1. Использование appImageAssistance
Если вы вручную собранные файлы, то вам нужно скопировать appname.рабочий стол файл из ./ usr/share / приложения в корень дерева каталогов. Также скопируйте файл с именем AppRun из другого приложения или извлечь его из AppDirAssistance.
2. Сделать .деб ор .rpm с использованием собранных файлов.

1

таким образом, ваши клиенты никогда не будут устанавливать какое-либо другое программное обеспечение, которое может указать другую версию тех зависимостей, которые вы ходите повсюду, верно?

почему бы просто не создать свой собственный дистрибутив, если вы собираетесь зайти так далеко?

или вы можете просто дать им кучу пакетов и один сценарий что ли rpm -i dep1 dep2 yourpackage

0