Одним из интересных анонсов (http://permalink.gmane.org/gmane.org.fsf.announce/2028), приуроченных к тридцатилетию проекта GNU, стал выпуск пакетного менеджера GNU Guix 0.4 (http://www.gnu.org/software/guix/) и публикация первого рабочего прототипа самодостаточного GNU/Linux дистрибутива на его основе. Дистрибутив оформлен в виде загрузочного образа (ftp://alpha.gnu.org/gnu/guix/) (120 Мб) для QEMU и предназначен для запуска в виртуализированных окружениях, инсталлятор для установки на отдельные разделы пока отсутствует.
Дистрибутив включает только свободные компоненты и поставляется с ядром GNU Linux-Libre 3.11, очищенным от несвободных элементов бинарных прошивок. Для сборки применяется GCC 4.7.3. В качестве системы инициализации используется сервисный менеджер GNU dmd (http://www.gnu.org/software/dmd/), развиваемый как альтернатива SysV-init с поддержкой зависимостей. Управляющий демон и утилиты dmd написаны на языке Guile (одна из реализаций языка Scheme), который также используется и для определения параметров запуска сервисов. Базовые образ поддерживает работу в консольном режиме, но для установки подготовлено (http://www.gnu.org/software/guix/package-list.html) более 400 готовых пакетов, среди которых и компоненты графического стека на базе X.Org, оконные менеджеры dwm и ratpoison, а также ряд программ на базе библиотеки GTK+.
Пакетный менеджер GNU Guix основан на наработках проекта Nix (http://nixos.org/nix/) и кроме стандартных функций управления пакетами поддерживает такие возможности, как выполнение транзакционных обновлений, возможность отката обновлений, работа без получения привилегий суперпользователя, поддержка привязанных к отдельным пользователям профилей, возможность одновременной установки нескольких версий одной программы, средства уборки мусора (выявление и удаление неиспользуемых версий пакетов). Для определения сценариев сборки приложений и правил формирования пакетов предлагается использовать специализированный высокоуровневый предметно-ориентированный язык и компоненты Guile Scheme API, позволяющие выполнять все операции по управлению пакетами на функциональном языке программирования Scheme.Поддерживается возможность использования пакетов, подготовленных для пакетного менеджера Nix и размещённых в репозитории
Nixpkgs (http://nixos.org/nixpkgs/). Кроме операций с пакетами возможно создание сценариев для управления конфигурацией приложений. При сборке пакета автоматически загружаются и собираются все связанные с ним зависимости. Возможна как загрузка готовых бинарных пакетов из репозитория, так и сборка из исходных текстов со всеми зависимостями. Реализованы средства для поддержания версий установленных программ в актуальном состоянии через организацию установки обновлений из внешнего репозитория.
Пакеты оформляются в виде контейнеров, содержащих все необходимые для работы приложений компоненты и позволяющие запустить приложение без оглядки на состав базового системного окружения. Между пакетами Guix возможно определение зависимостей, при этом для поиска наличия уже установленных зависимостей используется сканирование хэшей-идентификаторов в директории установленных пакетов. Пакеты устанавливаются в отдельное дерево директорий или поддиректорию в каталоге пользователя, что позволяет обеспечить его параллельное сосуществование с другими пакетными менеджерами и обеспечить поддержку широкого спектра существующих дистрибутивов. Например, пакет устанавливается как /nix/store/f6dvq84299f3249h8my6r9vs7a0n3-firefox-24.0.0/, где "f6dvq8..." является уникальным идентификатором пакета, используемым для контроля зависимостей.URL: http://permalink.gmane.org/gmane.org.fsf.announce/2028
Новость: http://www.opennet.me/opennews/art.shtml?num=38024
Не судьба сделать firefox-24.0.0-f6dvq84299f3249h8my6r9vs7a0n3 ?
радуйся, что не f6dvq84299f3249h8my6r9vs7a0n3
во-во ! и вообще, оставили бы такие "уникальные идентификаторы" для реестра. а то эти идентификаторы такие уникальные, что им для существования требуется специальный уход :|
Приходится иметь уникальные имена файлов в файловой системе. Добавление случайной строки -- это решение проблемы. Другое дело, что действительно неловко выходит -- работать с такими именами файлов будет затруднительно. Придётся отдельно возиться с тем, чтобы изменить порядок сортировки. Или искусственно создавать симлинки вида: /nix/symlinks/firefox-24.0.0-f6dvq84299f3249h8my6r9vs7a0n3 -> ../store/f6dvq84299f3249h8my6r9vs7a0n3-firefox-24.0.0 Мелочь, а неприятно.
Поиск по маске f6dvq8* гараздо быстрее поиска по маске *f6dvq8Вот что получается когда люди изобретают СУБД на основе имен файлов.
> Пакеты оформляются в виде контейнеров, содержащих все необходимые для работы приложений компоненты и позволяющие запустить приложение без оглядки на состав базового системного окружения.Перевод: с пакетом в комплекте идет всякое гуано мамонта, которое никто никогда не будет обнавлять. Енджой йо програм файлс.
Не нужно.
Бажный у тебя переводчик.
>При сборке пакета автоматически загружаются и собираются все связанные с ним зависимости....
Java + Maven ? :-)
Взаимоисключающие параграфы в эталонном виде.
Бинарный пакет без зависимостей, т.е. базовый набор библиотек и сервисов обновляется отдельно или меняется от версии дистрибутива? gobolinux (если не учитывать отход oт иерархии)?
Идея не плохая. Посмотрим, что из этого получится. Что меня смущает, так это широкое использование Guile. Scheme - очень простой и элегантный язык, но малопопулярный. Почему не использовали мейнстримный Java Script(его же теперь везде пихают)?
Какая разница, какой там язык?Но, всё же, можно предположить, что Guile -- это GNU проект, а мейнстримный js -- это не GNU проект. GNU -- это не мейнстрим, и не стоит ждать от него мейнстримных решений.
Да, идея неплохая:
1) Этот пакетный менеджер не конфликтует с системным пакетным менеджером
* Нужно только устранить конфликт конфигов
2) Этот пакетный менеджер решает конфликт библиотек и заголовочников для разных архитектур
* Правда, в нормальных пакетах это давно решено. Но некоторые мейнтейнеры продолжают косячить
3) Пакет будет дистронезависим.
* Привет, блоб!
Всё чаще и сильнее люди хотят контейнеры а-ля маковских.
Ничего удивительного: инсталляция программ, в большинстве случаев, сводится к простой распаковке из архива и перемещении в любое место, всё - программа готова к запуску. Это вам не виндовый реестр и не LSB.
> Ничего удивительного: инсталляция программ, в большинстве случаев, сводится к простой
> распаковке из архива и перемещении в любое место, всё - программа
> готова к запуску. Это вам не виндовый реестр и не LSB.Ну, и плюсы и минусы этого метода уже много раз обсуждались.
Есть и первое и второе. Тут скорее уже с родни религии.
PS: но так или иначе, сам таки за этот метод (all-in-one пакеты)
Смени ник, он тебе не идёт. Осиль чруты и LD_LIBRARY_PATH в конце-концов.
> Смени ник, он тебе не идёт.Ценная рекомендация. Спасибо.
>Осиль чруты и LD_LIBRARY_PATH в конце-концов.
А от чего достопочтенный сэр решил что я чего-то из этого не осилил?
Смею предположить что вы ЛОРакул, не меньше.
Будучи школьником мечтал о таком и даже начал писать его на /bin/sh. Приятно когда реализовывают твои мечты.
Что не так?
Если потребуется обновить libc, в скольких местах это потребуется сделать?
Libc, скорей всего, не входит в состав пакетов, кроме каких-то особых случаев зависимости от её версии. Libc есть в каждом дистре (куда же без неё), а glibc и eglibc совместимы.
А если софт из пакета использует новые фичи glibc, которых еще нет в дистрибутивной glibc?
> Если потребуется обновить libc, в скольких местах это потребуется сделать?Обновляться - это арчеводство. Любое обновление ломает стабильность™.