Использование Nix для упаковки зависимостей набора инструментов CentOS5 - PullRequest
0 голосов
/ 16 октября 2018

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

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

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

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

1 Ответ

0 голосов
/ 16 октября 2018

Это похоже на сценарий, в котором вам может помочь 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.

...