Использование Nix для упаковки зависимостей инструментальной цепочки CentOS5

В настоящее время мы изучаем, может ли Nix быть подходящим инструментом для упаковки сторонних библиотек и инструментов, необходимых для создания нашего программного обеспечения. Отказ от ответственности: я только что узнал о Nix и все еще пытаюсь собрать все воедино.

Наш продукт должен быть ABI-совместимым с системами CentOS5. Вот почему мы создаем наше программное обеспечение в контейнере CentOS5 Docker с помощью специально созданного GCC и множества других сторонних инструментов и библиотек, созданных из исходных текстов.

В настоящее время у нас есть один большой Makefile для построения всех этих зависимостей, и мы используем задание CI для построения зависимостей. Каждый раз, когда изменяется одна из зависимостей или выполняется какое-либо изменение в Makefile, мы перестраиваем все зависимости, что занимает много времени.

Вместо того, чтобы улучшать Makefile, мы ищем более простые решения, которые легче поддерживать. Я думаю, что Nix может помочь нам справиться с этой проблемой, переведя Makefile на отдельные производные с правильными зависимостями, указанными для каждой производной. Подойдет ли Nix для этого варианта использования? Основная проблема, которую я вижу, заключается в том, что Nix использует современную библиотеку glibc в качестве базовой производной, от которой мы не можем зависеть. Нужно ли нам создавать собственную версию glibc, или мы можем как-то зависеть от glibc, установленной в хост-системе (CentOS5)?


nix
person Ton van den Heuvel    schedule 16.10.2018    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Это похоже на сценарий, в котором Nix может вам помочь.

Наш продукт должен быть ABI-совместимым с системами CentOS5.

Бинарные файлы и библиотеки, созданные Nix (через Nixpkgs), не связываются с системными библиотеками. По сути, это похоже на статическое связывание, но достигается другими способами, такими как rpath и оболочка скрипты. Это должно сделать ваш продукт ABI совместимым с любым дистрибутивом, если ваша программа явно не требует определенных функций операционной системы, кроме обычных библиотек. Например, если ваша программа зависит от драйвера графического процессора, это все еще может быть проблемой.

со специально созданным GCC

Nixpkgs позволяет собрать все пакеты или только некоторые из них с помощью вашего пользовательского GCC.

с правильными зависимостями, указанными для каждой производной.

Nix идеально подходит для этой задачи. Я рекомендую строить с включенной функцией песочницы. Если вы не используете NixOS, вам следует установить его в многопользовательском режиме. и включите песочницу.

Основная проблема, которую я вижу, заключается в том, что Nix использует современную библиотеку glibc в качестве базовой производной, от которой мы не можем зависеть.

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

или мы можем как-то зависеть от glibc, установленного на хост-системе (CentOS5)?

Это подход, используемый в системах Mac OS X по необходимости. Это будет считаться шагом назад; для этого вам понадобится веская причина.

Подойдет ли Nix для этого варианта использования?

Тебе следует это попробовать. Nix может предоставить вам как минимум следующие гарантии:

  • Указаны все зависимости
  • Построенные параллельно производные одинаково верны
  • Каждая сборка представляет собой чистую сборку, даже если повторно используются результаты более ранних сборок.
  • Воспроизводимость: если он построен сегодня, он будет построен завтра, и вы можете изменить его завтра.
  • Полные зависимости: при установке никакие зависимости не будут исключены

Удачи и не стесняйтесь задавать вопросы. Программное обеспечение часто не любит, когда его заставляют вести себя должным образом.

и использовать задание CI

Полное раскрытие: я работаю над сервисом CI для Nix.

person Robert Hensing    schedule 16.10.2018
comment
Привет, Роберт, спасибо за подробный ответ. Когда вы говорите, что ваш продукт будет игнорировать системную glibc, это будет означать, что нам нужно упаковать glibc от Nix вместе с нашим продуктом? glibc и другие библиотеки необходимо будет перенести из хранилища Nix в отдельный каталог lib, например, в комплекте с инструментом. Думаю, это может потребовать переписывания заголовков ELF? Есть ли какой-нибудь канонический подход к этому? Я удивлен, что по этому поводу мало документации. Похоже, что большинство развертываний включает в себя и сам Nix, что в нашем случае не вариант. - person Ton van den Heuvel; 17.10.2018
comment
Я только что узнал, что последние версии glibc требуют более свежих ядер во время выполнения. Например, из электронного письма с объявлением glibc 2.26 (sourceware.org/ml /libc-alpha/2017-08/msg00010.html): во время выполнения требуется ядро ​​Linux 3.2 или новее на всех архитектурах, поддерживаемых этим ядром. (Это изменение по сравнению с версией 2.25 только для x86-32 и x86-64.). Поскольку CentOS5 использует 2.6.18 IIRC, я не думаю, что будет хорошей идеей объединять glibc, поставляемый с Nix, с нашим приложением ... - person Ton van den Heuvel; 17.10.2018
comment
Привет, Тон, я не знал о совместимости ядра glibc. Следующий лучший вариант - предоставить Nixpkgs более старую версию glibc. Я написал производную от предыдущего работодателя, которая превратила закрытие Nix в единый пакет RPM. Этого достаточно, если у вас нет риска столкновения зависимостей с другими такими пакетами. Вы можете создать пакет RPM для каждого производного в замыкании, чтобы при необходимости масштабировать его за пределы одного установленного пакета. - person Robert Hensing; 17.10.2018
comment
Роберт, интересная идея использовать RPM напрямую, спасибо за предложение. - person Ton van den Heuvel; 17.10.2018
comment
Вы можете использовать этот метод в качестве основы для создания пакетов RPM для каждого производного: github.com/NixOS/nixpkgs/blob/ - person Robert Hensing; 18.10.2018