0
- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
[ERROR] The compilation of ocaml-base-compiler failed at "/home/me/.opam/opam-init/hooks/sandbox.sh build ./configure -prefix /home/me/.opam/ocaml-base-compiler.4.02.3 -with-debug-runtime".
#=== ERROR while compiling ocaml-base-compiler.4.02.3 =========================#
# context 2.0.0 | linux/x86_64 | | https://opam.ocaml.org#12c8601e
# path ~/.opam/ocaml-base-compiler.4.02.3/.opam-switch/build/ocaml-base-compiler.4.02.3
# command ~/.opam/opam-init/hooks/sandbox.sh build ./configure -prefix /home/me/.opam/ocaml-base-compiler.4.02.3 -with-debug-runtime
# exit-code 2
# env-file /tmp/opam-me-3195/ocaml-base-compiler-3195-d6d332.env
# output-file /tmp/opam-me-3195/ocaml-base-compiler-3195-d6d332.out
### output ###
# ./configure: line 195: rm: command not found
# ./configure: line 196: touch: command not found
# ../gnu/config.guess: line 35: sed: command not found
# ../gnu/config.guess: line 1364: mkdir: command not found
# ../gnu/config.guess: line 1364: mkdir: command not found
# : cannot create a temporary directory in /tmp
# [ERROR!] Cannot guess host type. You must specify one with the -host option.
^ ...И так там со всем.
Кто там хотел попробовать "NixOS"? Могу поделиться впечатлениями: если вы надеятесь, что в этой оси можно будет пользоваться привычными "autotools", "opam" и "cabal", то фиг там. Из-за сломанного FHS ебаться с "Nix" придётся с первой минуты. cast @Роман
Запостил: 
CHayT,
25 Декабря 2018
Follow us!
Ты когда патчи тестируешь, тоже rpm-ки всегда собираешь? Системный софт это одно, а локальная помоечка — совсем другое.
Суть не в этом. Сорцы уровнем ниже, чем пакетный менеджер, они в принципе должны быть независимы от пакетного менеджера.
Суть в том, что в никсе вообще не может быть никакого "/usr/bin/sed" или "/usr/bin/python". Вся идея как раз в том, чтобы отказаться от глобального мутабельного стейта.
Разным программам могут быть нужны разные версии python, в никсе они могут сосуществовать, поэтому не понятно, какой из них должен лежать в /usr/bin.
Программы из сорцов в никсе собирают, это обычно делается примерно следующим образом: ты пишешь default.nix, в котором описано всё, что тебе нужно, чтобы собрать программу (sed, make, вот это всё). Потом ты вызываешь nix-shell, который открывает тебе шелл, в котором есть ровно то, что ты попросил, и ничего больше. Там ты можешь выполнить билд (make velik / cabal new-build velik /dune velik.exe) и поиграться с результатами. См. пример [1].
Такие окружения полностью герметичны и воспроизводимы, не то что всякие "virtualenv".
К сожалению, нужно таки писать default.nix. С другой стороны, если ты патчишь эрланг, можно написать один раз и накопипастить готовых определений.
[1] https://ariya.io/2016/06/isolated-development-environment-using-nix
Да, докер является одним из решений.
autotools пытается угадать, что где лежит, многие зависимости опциональны. Завязывать сборку какого-нибудь ынтерпрайзного софта на autotools -- это самоубийство.
> дефакто в мире GNU
В мире GNU происходит много чего.
> но там есть спец люди (портеры) которые этим занимаются.
в nix тоже есть спец-люди, просто если ты сам что-то новое пилишь или сидишь в ынтерпрайзе, то писать надо тебе.
Хотя на сервер `NixOS' и интересно было бы вкатить.
командой, исполняемой программой или пакетным файлом.
> # ./configure: line 196: touch: command not found
либо chroot поломали (если он используется), либо $PATH кто-то грохнул (`env -`?).
на практике видел и первое и второе.
"каждый апп в своем пакете и окружении" относится только к end-user приложениям (e.g. FireFox or OpenOffice). и базовое окружение (кернел/дрова + либы + тулзы) как правило берется из самой ОС. пакеты с приложениями компилирутся на основе этого базового окружения - и в рантайме приложение им же и пользуется.
новая мода. меня не сильно впечатлило.
ЗЫ немного напомнило старую моду. все недостатки static linking, одновремменно с отсутствием всех преимуществ static linking.
бсд ставит софт локально.
на таких системах - выплевывается пакет приложения с зависимостями (которые базовая система не предоставляет).
> значит, всё таки не читал.
теперь прочитал. ;)
все равно смысла мало вижу в прочитаном - надо руками щупать.
потому что, например - "Отказ от использования глобальных каталогов, таких как /bin, позволяет существовать нескольким версиям пакета." - не имеет никакого смысла. потому что кто-то/что-то должно управлять этими "несколькими версиями пакетов".
я как раз поэтой причине и ковырял эту херню, потому что не мог понять как это может в принципе работать. в одной коммерчески используемой системе (хоть убей не помню имени) ковырял. и я там нашел 250MБ имадж с базовой системой, поверх над которой делался chroot для пакета приложения.
поэтому это по большей части просто пиздёж что там *все* в отдельные рандомные каталоги разложено.
как минимум бутстрап, кернел, init, окружение для инита, и манагер пакетов (+ ихние зависимости, что уже 100+МБ с лёгкостью) должны лежать в заранее известных каталогах.
Доставка по России. Анонимно.
[email protected]
уж rm то могли бы в шелл встроить
чай не 1978-й год
Настройка демона хранится по умолчанию в файле
/var/lib/systemd/system/systemd-rmd.unit
и в сорока семи файлах в папке
/etc/systemd/system/systemd-rmd.unit.d
редактировать файлы напрямую не рекомендуется, нужно использовать утилиты.
Допустим, чты хочешь, чтобы rm не удалял корень.
Нужно дать комманду
$ systemct systemd-rmd options add option preserve-root
Тогда появится файл
/etc/systemd/system/systemd-rmd.unit.d/199-systemd-rmd-preserve-root.conf
с небольшим JSONом внутри, в котором будет зашифрована эта команда