NuTyX и Vivaldi

Алексей Федорчук

nutyx-logo-red_120x112

Репозиторий NuTyX’а не может похвастаться изобилием пакетов — это с одной стороны. Со стороны же другой, не отягощён он и вниманием со стороны независимых разработчиков. Правда, всё необходимое для жизни мы с котом Manual’ом в официальном репозитории обнаружили — кроме среды Cinnamon, разумеется, но это совсем отдельная тема. А вот немало из роскошного — нет. Но ведь всем известно, что без роскошного прожить гораздо сложнее, нежели без необходимого.

Особенно если это роскошное не относится к миру открытого и свободного софта, как, например, полюбившийся нам в последнее время браузер Vivaldi, который развивается с такой научно-фанстастической силой, что имеет шанс участвовать в конкурсе на лучший браузер всех времён и прогрессивных народов. Но, однако, распространяется только в виде deb- и rpm-пакетов. Для него не имеется даже абстрактного тарбалла, пригодного, по крайней мере, теоретически, для установки в столь же абстрактный «любой Linux».

Однако нас с котом Manual’ом не проведёшь: мы ведь знаем (как, уверен, знает и наш читатель), что и deb-, и rpm-пакеты — такие же архивы, как любые другие. Ну там в них для важности кой-чего добавлено — но в данном конкретном случае как раз эта важность и не важна.

Так что мы с котом Manual’ом поступили очень просто. Сначала скачали то, что нам дают на официальном сайте Vivaldi (мы качали deb-пакет, но можно и rpm, разницы нет). Затем развернули deb-пакет — проще всего это сделать через Mindnight Commander, запущенный от root’а (предварительно mc надо установить, в базовой коллекции NuTyx’а его нет).

Внутри обнаружилось три каталога — etc, opt и /usr. Первый и последний отсавляем в покое, а во втором видим подкаталог vivaldi, который тупо копируем в /opt файловой иерархии NuTyX’а. И пытаемся запустить (уже от пользователя):

$ /opt/vivaldi/vivaldi

В ответ на столь наглое бесчинство получаем сообщение, что это сделать невозможно без пакета gconf. Немедленно устанавливаем последний:

$ get gconf

И повторяем попытку запуска — опять безуспешно, с жалобой на неправильные атрибуты принадлежности и доступа для файла /opt/vivaldi/vivaldi-sandbox.

Делаем их правильными:

$ sudo chown root:root vivaldi-sandbox
$ sudo chmod 4755 vivaldi-sandbox

Снова запускаем Vivaldi тем же образом, что и ранее. И наблюдаем экран его первичной настройки. Проскочив их галопом по европам, убеждаемся, что браузер работает:

nutyx_030

Порядку ради создаём символическую ссылку:

$ sudo ln -s /opt/vivaldi/vivaldi /usr/bin/vivaldi

Дальше можно добавить соответствующий пункт в главное меню используемого десктопа, скопировать из архивного usr/share в /usr/share «всамделишний» иконки и прочие служебные файлики. Но в виртуалке заморачиваться этим мы не стали — ибо на данном этапе требовалось тольк убедиться, что проблема в принципе решаема. А уж косметикой будем заниматься в реале — если потребуется.

Оглавление цикла

NuTyX и Vivaldi: 8 комментариев

  1. Спасибо. Оригинальное решение! Возьму на заметку.

  2. Pkgfile для браузера vivaldi уже создан пользователем greg.
    Он же может служить примером скрипта для перепаковки бинарных пакетов такого типа — google-chrome, viber и др.
    Скачать порт для некоторых пакетов можно на git’е:
    https://github.com/NuTyX/nup

    Как это получилось у меня.
    Я скачал с git’а файл-архив nut-master.zip
    С помощью mc скопировал каталоги nup и nup-extra в каталог с портами /usr/ports/
    Затем переход в каталог с Pkgfile для Vivaldi:

    cd /usr/ports/nup-extra/vivaldi

    Скомпилировал пакет:

    sudo pkgmk -d

    И установил:

    sudo pkgadd vivaldi*

    Всё получилось… :-)

  3. Немного разобрался с пакетированием. Отличный дистрибутив в плане «под себя». Даже создал маленький архивчик для себя.
    https://github.com/cdrw-nutyx/NuTyX-Pkgfile
    Плавно переплываю из Slackware в NuTyX…
    :-)

  4. Артур, мне он тоже нравится. И будь я помоложе, или осталось бы больше энтуазизьму…
    А так — для практической работы в нём нет многого очень мне нужного (начиная со среды Cinnamon).
    А собирать это самому — тогда в этой жизни не успею дописать и половины из начатого. Половину из которой половины обещал дописать раньше, чем сдохну :)

  5. И да, спасибо за ссылку. Иногда одолевает искушение всё бросить и уехать в Урюпинск таки заняться NuTiX’ом…

  6. Cinnamon?
    Попробую… Чем черт не шутит… Хотя я в нем даже не работал…
    :-)

  7. Я пытаюсь продолжить Вами начатое, но талант не куст — не вырастет.
    Вот пример, но самому даже не читается…

    Создание окружения chroot

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

    В NuTyX окружение chroot устанавливается в каталог /mnt/hd. Устанавливаются пакеты из коллекции base, самый минимум, самодостаточный для сборки пакетов без зависимостей. Так же устанавливаются пакеты с инструментарием для компилирования исходников и заголовочные файлы, требуемые многими пакетами при компиляции. Это делается командой get cards.devel

    Как работает система при создании нового пакета.

    Допустим, мы хотим создать простенький пакет, который не требует зависимостей. Это для начала. Пишем рецепт (Pkgfile) для компиляции и создания пакета и помещаем его в свой персональный порт для наших рецептов, в каталог одноименный с названием компилируемого пакета. Если по ошибке название каталога не совпадет с названием пакета, cards откажется создавать пакет и укажет на несоответствие имен пакета и каталога. Наш персональный chroot‘овый порт находится по адресу /usr/ports/perso, а из хостовой системы он будет доступен как /mnt/hd/usr/ports/perso!

    У нас в наличии две системы портов — пользовательская, по адресу /usr/ports/perso и chroot‘овая, по адресу /mnt/hd/usr/ports/perso. В окружении chroot находится главная «кузница» наших пакетов, а в основной системе можно создавать одиночные пакеты, такие как шрифты, пакеты со скриптами и т.д… Короче, по мелочи и без зависимостей. Не спутайте эти две системы при создании пакетов.

    Для создания нашего пакета служит команда cards create -r mypackage… Для ее выполнения не обязательно находиться в каталоге создаваемого пакета. Cards сам найдёт Pkgfile пакета, по названию. После создания пакета, он будет доступен для установки в основной системе простым пользователем. Надо дать команду get mypackage как простой пользователь и пакет благополучно установится.

    Для того, чтобы основная система знала где искать созданный нами пакет в окружение chroot, нужно в первой строке конфигурационного файла cards основной системы (/etc/cards.conf) указать путь к порту, где мы его создали — /mnt/hd/ports/perso. В этом случае пакет будет найден и благополучно установлен.

    Общий принцип, я думаю, понятен.

    Теперь рассмотрим, как работает процесс компилирования пакета в окружении chroot.

    Пакеты для chroot‘а устанавливаются из портов, теперь уже в роли репозитория, по прямому адресу: /mnt/hd/usr/ports/. Там три коллекции пакетов — base, cli и gui. Мы их туда загрузим с помощью команды rsync. Операция эта проводится один раз, никаких обновлений не требуется, если вы конечно сами не полезете туда и чего нить там не наудаляете. Этих серий обычно достаточно, но если потребуется какой нибудь пакет в качестве зависимостей из других коллекций пакетов, придётся добавить еще коллекцию. Мне пришлось добавлять коллекцию cli-extra, так как одному из пакетов compiz’а, который я компилировал, потребовался инструмент cython, который обнаружился в коллекции cli-extra.
    По умолчанию, в окружении chroot установлены пакеты из коллекции base и те, что входят в список cards.devel. В рецепте (Pkgfile) вы должны прописать зависимости сами, за вас это никто автоматом не сделает. Делается это в Pkgfile примерно так:
    # Depends on: gtk3 perl python

    Перед компиляцией, cards установит пакеты-зависимости указанные вами, плюс зависимости, которые требуются устанавливаемым пакетам. Если они конечно есть в этих коллекциях. Я уже упоминал пакет cython, которого не оказалось в этих трех каталогах, пришлось тупо загрузить каталог cython с рецептом Pkgfile в мой perso из коллекции cli-extra и просто создать его в качестве пакета-зависимости. Другим вариантом решения проблемы, может быть загрузка всей серии cli-extra в /mnt/hd/usr/ports и прописка ее в /etc/cards.conf. Cards тогда сам обнаружит этот пакет и установит. Но в моём случае, это был всего лишь один недостающий пакет. Так что я сильно не напрягался. Но затем опробовал и второй вариант, из любопытства.
    Как вы поняли, cards читает рецепт, выясняет какие там зависимости вы понаписали ему, устанавливает их и, если всё без ошибок, компилирует, создает и устанавливает пакет в окружении chroot. Вы можете даже попытаться запустить его в окружении chroot, если это самодостаточный для работы пакет. Если всё получилось, открываем окно консоли, и как простой юзверь, устанавливаем созданный пакет командой get mypackage.
    Теперь в окне консоли, где мы колдовали в сеансе chroot, можно дать страшную для основной системы команду cards base –r. Она удалит все установленные в процессе компиляции пакеты и вернет состояние окружения chroot к исходному, то есть оставит только набор пакетов base + cards.devel. Все остальное будет удалено. Можно не давать эту команду, при следующей компиляции cards первым шагом сам это сделает.

    ВНИМАНИЕ!!!
    Не давайте эту команду в основной системе!!! Снесёт к чёртовой матери всё, что вы там наустанавливали, все ваши настройки и старания. Останетесь с голой base и недовольным выражением лица. И не говорите, что вас не предупреждали!!! Ею можно воспользоваться, когда вы решили начать всё с чистого листа. Допустим у вас стоял MATE, а вы решили попробовать на сколько быстрее «чистый» LXDE. Чтобы не переустанавливать NuTyX заново, эта команда как раз на руку.
    Теперь разберемся немного с конфигами команд cards и pkgmk.

    В общих чертах, в деталях, это надо уже маны смотреть. Cards работает с портами, занимается установкой и удалением пакетов. Это его прямые обязанности. А вот компилирует и создает пакеты — pkgmk, его подчиненный. Соответственно и конфиги у каждого свой.
    Pkgmk умеет создавать полный пакет в сборе, как у Slackware. А может разбивать его на подпакеты, man‘ы отдельно, языковые (ru, de, fr…) подпакеты отдельно, отдельно подпакет devel… Может не сжимать пакеты, просто tar и всё, а может так сжать за X (xz), что мама не горюй. Всё это настраивается в /etc/pkgmk.cong. Там, с помощью переменных, определяется режим работы скрипта. За подробностями в руководства. Можно пользоваться установками по умолчанию, меня вполне устраивает допустим.
    Пример /etc/pkgmk.conf

    Это пример конфига pkgmk для chroot окружения.
    export CFLAGS=»-O2 -pipe»
    export CXXFLAGS=»\${CFLAGS}»
    case \${PKGMK_ARCH} in
    «x86_64″|»»)
    export MAKEFLAGS=»-j$(getconf _NPROCESSORS_ONLN)»
    ;;
    «i686″)
    export MAKEFLAGS=»-j$(getconf _NPROCESSORS_ONLN)»
    export CFLAGS=»${CFLAGS} -m32″
    export CXXFLAGS=»${CXXFLAGS} -m32″
    export LDFLAGS=»${LDFLAGS} -m32″
    ;;
    *)
    echo «Unknown architecture selected! Exiting.»
    exit 1
    ;;
    esac
    PKGMK_SOURCE_DIR=»/tmp»
    PKGMK_KEEP_SOURCES=»yes»
    PKGMK_WORK_DIR=»/tmp/work»
    PKGMK_IGNORE_REPO=»no»
    PKGMK_IGNORE_COLLECTION=»no»
    PKGMK_GROUPS=()
    PKGMK_LOCALES=(ru)
    PKGMK_COMPRESS_PACKAGE=»yes»
    PKGMK_COMPRESSION_MODE=»xz»
    PKGMK_CLEAN=»no»
    PKGMK_IGNORE_RUNTIMEDEPS=»no»

    Установлены флаги процессора, в рецепте их указывать не нужно, как это делается в Slakware.
    Определен рабочий каталог, куда будут распаковываться исходники (/tmp/work) и собираться пакет.
    Сами исходники будут загружаться в каталог /tmp и там сохраняться, удаление запрещено.
    Файлы локализации будут оставляться только русские (ru)
    Пакет будет сжиматься компрессором xz.

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