1. bash / Говнокод #25222

    0

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 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

    Комментарии (50) RSS

    • seo: NixOS is too good for this world, too pure
      Ответить
      • показать все, что скрытоvanished
        Ответить
      • показать все, что скрытоvanished
        Ответить
        • показать все, что скрытоvanished
          Ответить
        • > Слушай, ну на никс надо всё ставить через nix, это же очевидно а не с сыруов.
          Ты когда патчи тестируешь, тоже rpm-ки всегда собираешь? Системный софт это одно, а локальная помоечка — совсем другое.
          Ответить
        • > Ты же не будешь пытаться запустить pkgsrc на centos, а rpm на solaris?

          Суть не в этом. Сорцы уровнем ниже, чем пакетный менеджер, они в принципе должны быть независимы от пакетного менеджера.

          Суть в том, что в никсе вообще не может быть никакого "/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
          Ответить
          • показать все, что скрытоvanished
            Ответить
            • > решается докером

              Да, докер является одним из решений.
              Ответить
              • показать все, что скрытоvanished
                Ответить
                • Идеология разная.

                  autotools пытается угадать, что где лежит, многие зависимости опциональны. Завязывать сборку какого-нибудь ынтерпрайзного софта на autotools -- это самоубийство.

                  > дефакто в мире GNU

                  В мире GNU происходит много чего.
                  https://www.gnu.org/software/guix/


                  > но там есть спец люди (портеры) которые этим занимаются.

                  в nix тоже есть спец-люди, просто если ты сам что-то новое пилишь или сидишь в ынтерпрайзе, то писать надо тебе.
                  Ответить
    • Именно поэтому я против ОС.
      Ответить
    • Именно поэтому я за 『Gentoo』.
      Ответить
    • А ты что думал, для всего теперь деривейшены писать надо.
      Ответить
      • показать все, что скрытоvanished
        Ответить
      • Для админов может это и хорошо, что можно админить не вынимая руки из жопы, ибо всё легко откатить. Но для девелоперов такая жизнь боль: у меня одних эрлангов локально стоит штук семь, разных версий и с разными патчсетами, с деревяшными такое собирать с ума сойдёшь.
        Хотя на сервер `NixOS' и интересно было бы вкатить.
        Ответить
    • показать все, что скрытоvanished
      Ответить
    • показать все, что скрытоvanished
      Ответить
    • > # ./configure: line 195: rm: command not found
      > # ./configure: line 196: touch: command not found

      либо chroot поломали (если он используется), либо $PATH кто-то грохнул (`env -`?).

      на практике видел и первое и второе.
      Ответить
      • показать все, что скрытоvanished
        Ответить
        • нет. но тред читал. роли не играет. с подобными системами работал. на таких системах всегда есть базовый пакет (или даже два - один для нормального окружения, второй для chroot компиляты), который отвечает за базовае тулзы.

          "каждый апп в своем пакете и окружении" относится только к end-user приложениям (e.g. FireFox or OpenOffice). и базовое окружение (кернел/дрова + либы + тулзы) как правило берется из самой ОС. пакеты с приложениями компилирутся на основе этого базового окружения - и в рантайме приложение им же и пользуется.

          новая мода. меня не сильно впечатлило.

          ЗЫ немного напомнило старую моду. все недостатки static linking, одновремменно с отсутствием всех преимуществ static linking.
          Ответить
          • показать все, что скрытоvanished
            Ответить
            • > ну ты прямо бздёвую бейзсистем описываешь

              бсд ставит софт локально.
              на таких системах - выплевывается пакет приложения с зависимостями (которые базовая система не предоставляет).

              > значит, всё таки не читал.

              теперь прочитал. ;)

              все равно смысла мало вижу в прочитаном - надо руками щупать.

              потому что, например - "Отказ от использования глобальных каталогов, таких как /bin, позволяет существовать нескольким версиям пакета." - не имеет никакого смысла. потому что кто-то/что-то должно управлять этими "несколькими версиями пакетов".

              я как раз поэтой причине и ковырял эту херню, потому что не мог понять как это может в принципе работать. в одной коммерчески используемой системе (хоть убей не помню имени) ковырял. и я там нашел 250MБ имадж с базовой системой, поверх над которой делался chroot для пакета приложения.

              поэтому это по большей части просто пиздёж что там *все* в отдельные рандомные каталоги разложено.

              как минимум бутстрап, кернел, init, окружение для инита, и манагер пакетов (+ ихние зависимости, что уже 100+МБ с лёгкостью) должны лежать в заранее известных каталогах.
              Ответить
    • ># ./configure: line 195: rm: command not found
      уж rm то могли бы в шелл встроить
      чай не 1978-й год
      Ответить
      • за такое могут и поттерингом обозвать
        Ответить
        • нет, у поттеринга был бы systemd-rmd: демон, слущающий D-Bus, и удаляющий файлы по команде.

          Настройка демона хранится по умолчанию в файле
          /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ом внутри, в котором будет зашифрована эта команда
          Ответить
          • зато часть параметров в rm можно было бы не передавать
            Ответить
            • Зачем ограничивать себя? Ведь жизнь так коротка.
              Ответить
              • не ограничивай себя тремя измерениями! стань четырехмерным для начала!
                Ответить
                • Сколько бы вы меня не меряли, последнее слово (предсмертный бред) будет за инкубаторами. Ваши жалкие потуги по изобретению вакцины напоминают попытку затащить папу-Кролика в загс.
                  Ответить
          • Напоминает «Дебилиан» и ещё один дистрибутив с африканским названием.
            Ответить
    • показать все, что скрытоvanished
      Ответить

    Добавить комментарий